FAQs for Runnnng Rational Team Concert on DB2 for z/OS Database
Strongback works with many large mainframe customers, in the financial services, government, insurance, and manufacturing sectors. We’ve been involved in quite a few migrations from various SCM systems to Rational Team Concert. Most of these customers choose to run Team Concert with a DB2 backend running on z/OS (DB2z). As such, we often run into the same questions and concerns. Some of which are already explicitly addressed in the IBM Knowledge center. Some is addressed in the Jazz.net deployment wiki. This post is mean to address as much of those questions and concerns as we can. We’ll update this post in the future as needed. If you choose to use DB2 on z/OS for your CLM environment, we first encourage you to go through all the following items in the IBM Knowledge Center:
If we are are a mainframe shop running Team Concert, should we use the DB2 on our mainframe or should we set up DB2 on a distributed server?
You do not have to use DB2 on z/OS. It does not matter if your’re using RTC for your COBOL source code. Sometimes it can actually be advantagous to use a distributed server, because it keeps your mainframe DBA’s out of the process. Another reason why you wouldn’t want your DB2 on z/OS is CPU load (even though it’s using the zIIP processor). Most shops run their mainframe at 100% CPU capacity and running development workloads such as what RTC/CLM require is adding to that load, and subsequently may not have enough resources to run at optimal desired performance for the user community.
However, if you already have solid SLA’s and disaster recovery mechanisms in place for DB2/z along with enough available CPU resources, and experienced DBA’s, then DB2 on z is a reasonable choice.
As a background, RTC uses a database to store source code, work items, reports, build results, and more. It is an extremely complex database, and not one that any DBA should be tinkering with. In fact, you will never access its database directly. Ever. Nor should you. Even when we build extensions and customizations for an environment we only go through the RTC web services (REST) API, or its native Java API. These are not databases that need monitoring like your database for your in house applications. These are considered product databases. Thus, it is more of a matter of service level expectation, and manageabilty (backup and recovery, DR) rather than it is about DBA maintenance.
Why do I have to use the script processing that comes with RTC instead of the process that we use for all other table allocations?
Because there are hundreds of tables in RTC and the database is hyper-normalized. Doing so manually, and correctly would take weeks, and be fraught with errors. RTC creates these not through DDL scripts, but through Java which makes it very difficult to extract into DDL. These databases are managed entirely by RTC. Do not use any other method other than the repotools commands to create the tables. You have been warned. If you are running Team Concert on z/OS Liberty instance, use these steps. If your server is running on Linux or Windows, use these steps. If you resist and insist on having your DBA’s manually create the databases, you are on track for a failed implementation.
Why do I have to create a specific id for access to RTC databases?
The databases will be accessed by the Team Concert server exclusively. No other user should have access to these databases directly, nor should this user have access to any other databases in your system. While this is not a technical limitation (you can use an existing user), but we HIGHLY discourage it for security and auditing purposes.
Follow the steps in this link exactly: https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.5/com.ibm.jazz.install.doc/topics/t_rtcz_setting_up_db2.html
Why do I have to use DBADM for the database user?
Having DBADM access allows the RTC server setup to proceed without failure, and this includes creating tables, views, inserting and deleting rows, managing tablespaces, running stored procedures and more. These are created progammatically through RTC’s setup scripts. The DBADM user must be able to create and drop tables, select, insert, delete, and update those tables, run statistics on the tables and also to be able to create a deadlock monitor for Jazz and have use of the user temporary table space. You must make sure you run the DB2 GRANT commands as documented also. The DB2 ID used by RTC should have DBADM priviledges, and for security, this ID should only be used for these RTC databases, with no 3270 login authority. If you do not grant DB2ADM authority, your DBA’s will have a exceedingly “fun” time manually creating tables, views, triggers, etc.
Follow the steps in this link exactly: https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.5/com.ibm.jazz.install.doc/topics/t_rtcz_setting_up_db2.html
What size should I make the tables?
It depends. There is no hard rule of thumb about this, because the database sizes can grow differently depending upon your usage and audience. Please read the Impact of Data Repository Size section in the following Jazz Deployment Wiki link
If you need help sizing the solution and coming up with a reasonable estimation (and you are not already working with us), please contact us.
Why cant I easily move the database from a Test DB2 instance to PROD?
Actually, you can. As of recent versions, IBM has provided JCL’s to accelerate the ability to unload and load databases. This includes specific instructions to load data back to a new or different database, which is convenient for setting up a test/staging environment that mirrors your production environment.
There is another method, which may or may not be easier and faster, depending upon the size of your databases. You can use the repotools commands to export the data and then import it. This is done on the Team Concert server itself using the command repotools-ccm.sh -export (and similarly repotools-jts.sh for the JTS database, and similar commands for each respective database).
Keep in mind, that if you are setting up a staging environment from your production CLM databases, you will have to do a server rename on the Test/Staging server before using it. You cannot just unload/load and start the server. It will not work and is likely to corrupt your production system as the TEST environment has yet to be configured. Again, if you need help setting up a TEST/Staging RTC environment, please contact us.
What portion of databases for Collaborative Lifecycle Management will we be installing ( JTS, CCM, RTC, DCC, QM, RM, DW)? I’m confused about the ‘DCC (data warehouse)’ .
DCC Is the data collection component. It is used to run Extract Transform and Load (ETL) tasks. It stores data in its database (DCC) including report configurations , and transforms data to store into the data warehouse (DW). This provides the ability to do historical reporting and feeds into RTC’s built in dashboards (burn downs, burn ups, team velocity reporting, etc). See the following link to learn more about the DCC. We recommend running it, and have often found that when customers did not set it up at the beginning, would complain about the lack of reports available, only to end up setting up the DCC to get those very reports. Think ahead! Set it up early. Learn more about the data collection component.
The other databases are described below:
- CCM = Change and Configuration Management. This is the Team Concert database that contains your source code, work items, build definitions and results, etc.
- JTS = Jazz Team Server. This is the core database that links all other CLM applications via Lifecycle Projects. It also stores personal dashboard information. You will have at least one of these for each CLM environment.
- DCC = Data Collection Component.
- DW = Data Warehouse.
If you are only using Team Concert, the remaining databases may not be needed. They are described below:
- RM = Requirements Management. This the database that backs DOORs Next Generation, the requirements management tool of CLM.
- QM = Quality Management. This is the database that backs Rational Quality Manager, the product that handles test plans, test suites, test cases, and test execution results.
- LQE = Lifecycle Query Engine. This is a database system used to track lifecycle data across multiple CLM tools. If you are only using RTC, you may not need this database. If you have RTC and any of DOORs, RQM, or design Manager, see this link.
- LDX = Link Index Provider. Builds and maintains an index of links between artifacts in different project areas. Used when installing multiple CLM applications (RTC, DNG, RQM, etc).
- RELM = Rational Engineering Lifecycle Manager. Rarely used in z/OS environments. Used for engineering based projects.
- GC = Global Configuration Management. This is most often used in a full CLM stack (RTC, DNG, RQM).
So based on the link below I see that there is an actual Data warehouse database and than there looks to be Job that are run to load the database is this correct there is only 1 database needed and then a process that load the database?
There is no “job” to load the datawarehouse per se. Rather it is part of the RTC setup (https://<yourservername>/jts/setup) that actually creates the tables for each application in the datawarehouse. Thus you should have 4 total databases assuming you are only using Team Concert with the data warehouse (CCM, JTS, DCC, and DW).
Does a special storage group need to be defined if we have SMS managed storage groups?
Yes, it does.
How is the sizing specified if the DDL is in a ‘black box’ and executed by the command provided? Also, who is going to work on determining the sizing of these databases? We have been given the following link and it starts with knowing the number of users expected.
Sizing is not governed or limited by the application setup (aka internal “DDL”). See the link above, and particularly, the section on “Miscellaneous assumptions and caveats”. Our group can help with this.
We would like to know if there are special system settings/zparms required or suggested for this product?
Yes. TBSBPLOB See the link below.
There are specific links in the knowledge center for setting up DB2 for z/OS: https://www.ibm.com/support/knowledgecenter/en/SSYMRC_6.0.5/com.ibm.jazz.install.doc/topics/t_rtcz_server_installation_db2zos.html
How often are new tables / views created in the RTC product?
Tables and views are updated frequently, and updates to the schemas nearly always come with RTC updates and new versions (i.e. 6.0.4 to 6.0.5).
On installs for other companies, do they typically install the databases in an existing sub-system or create new ones?
Yes to both. Its really a matter of managability. Some use existing subsystems that have well defined SLA’s. Others create new subsystems to isolate RTC and provide specific SLA’s. While this is a customer preference, I personally prefer the latter, so as not to compete with production workloads, or be influenced by events like performance testing. It helps to isolate WLM to guarantee a minimum level of performance to RTC databases so as to avoid having developers sit and wait for their code to check in, or work items to update. Idle developers are expensive, and often vociferous about crappy performance.
DB2 Resources
DB2 for z/OS Pre requisites:
Team Concert (and Jazz based products) Planning and Design Wiki:
Need help implementing Rational Team Concert for z/OS?
If your organization is struggling with getting going, let us help. This is our bread and butter type of project.
