Using IBM Rational Team Concert for System z and the Jazz platform: Part 4. How cross-system development with Rational Team Concert for System z works

Combinations for teams of mainframe and Web application developers

Most applications rely on the cumulative strengths of the mainframe and distributed pieces. The mainframe pieces typically focus on implementing the persistence and business logic of the application; whereas, the distributed pieces provide the Web front end. The glue between the two might be a Web service. However, integrating two different kinds of software development teams and their processes creates a new set of challenges. This article shows how IBM® Rational Team Concert™ for System z® works with other Rational software as a collaborative management tool both for mainframe and Web application development.


Nicolas Dangeville (, Software Architect, Rational Enterprise Modernization, IBM

Author photoNicolas Dangeville is the chief architect of Rational Team Concert for System z. He is part of the IBM France Software Laboratory, in Paris, and has been involved in various software projects, including the IBM VisualAge Pacbase convergence plan.

Tami Takamiya (, Software Engineer, Rational Enterprise Modernization, IBM

Author photoTami Takamiya joined IBM in 1989 and has worked on various software projects, including Personal Communications, IBM WebSphere Host On-Demand, and Rational Host Access Transformation Services (HATS), both in Yamato, Japan and Research Triangle Park, North Carolina, in the U.S. Since 2008, he has been working on Rational Team Concert for System z and primarily involved in the design and implementation of the mainframe application build component.

Hung Lam (, Software Engineer, Rational Enterprise Modernization, IBM

Hung Lam photoHung Lam is a software engineer at IBM in Research Triangle Park, North Carolina. He joined IBM in 1999 and has worked on several projects including Communications Server for Windows NT, IBM WebSphere Host Publisher, and IBM WebSphere Host Access Transformation Services. He is currently a developer of Rational Team Concert for System z.

25 February 2010

Also available in Portuguese

This is the fourth article of a series about IBM® Rational Team Concert™ for System z® (called simply Rational Team Concert hereafter). In this article, we focus on setting up components and streams in Rational Team Concert to optimize cross-system development.

This article uses the same cross-platform application that we used as an example in the second article of this series (see "More in this series") to demonstrate how IBM® Rational® Developer for System z® (sometimes referred to as just Rational Developer hereafter) and Rational Team Concert work together.

Note: Some of screen captures in this article have been edited to make them easier to read.


The scenario for this article is based on a development team that is responsible for maintaining a cross-platform mortgage payment application. The business logic for the application is in a set of IBM® CICS® program modules. Persistency of the application is managed in Virtual Storage Access Method (VSAM) files and an IBM® DB2® database. This application has a Java™-based Web user interface running in IBM® WebSphere® Application Server software that invokes the CICS transaction through a Web service call. All source members of the application are managed in the Rational Team Concert for System z source control repository. The development team includes the mainframe and distributed sub-teams, which are responsible for mainframe and distributed pieces, respectively.

The development team has just delivered a major release of the application. Now the team is ready to start the development of the new release and needs to keep both mainframe and distributed (Web applications) parts in sync. In the sections that follow, we describe how the team can organize their team areas and artifacts and set up their process to accomplish their goals.

Set up components and streams

In this section, you'll learn how to set up everything that each team needs to work separately yet successfully integrate their work.

Rationale for the setup

Project area setup details

A single project area has been created with two team areas. One is for Mainframe Development team, and the other one is for Distributed Development Team. Each team will have its own stream to store the source code and other artifacts. Each stream will contain several exclusive and common components. A shared development integration stream is required for both teams to share code between them. In addition to the development streams, there will be two additional streams for promotion purposes. These are all of the streams used in this example (also see the screen capture in Figure 1):

  • Dev Integration Stream (Mortgage Application)
  • Distributed Dev Stream (Distributed Dev Team)
  • Mainframe Dev Stream (Mainframe Dev Team)
  • QA Stream (Mortgage Application quality assurance)
  • Test Stream (Mortgage Application)

The development tasks for the mainframe and distributed teams are different. Although they will use the same project area to manage their artifacts, define their plans, and exchange work items, each team wants a place where they can develop new functions without interfering with the other team before the code is stable. After it is stable, they want the teams to integrate the solution.

Therefore, each team will own a dedicated stream where they can share and build the artifacts being developed. It is understood that the build can fail at this level; however, the team members will try to deliver and share artifacts that can be built safely.

The mainframe and distributed teams are connected, because each team is working on an aspect of the same application. The connection between the teams is represented by the definition of a Web service.

The two teams have agreed to integrate stable code every week. For this purpose, an integration stream has been created containing both the mainframe and distributed artifacts, and they run a weekly build against these artifacts in this integration stream. This does not mean that all developments of each team need to be frozen and stable each week. For the weekly integration, the teams have committed to share artifacts that are stable and are expected to build safely with the other team's artifacts.

The overall process requires the clear management of code at each level of the development process: development code, test code, and production code. For this reason, a stream that contains the code for the test and a stream that contains the code for QA (quality assurance) have been set up, with dedicated builds.

An administrative user is required to set up the teams and streams. See the sidebar for how the project area is set up.

Figure 1. Streams used in this example
Streams within the Source Control folder

Team areas

Two development team areas are required, because the Mainframe Dev Team is responsible for maintaining the backend CICS program modules, and the Distributed Dev Team is responsible for maintaining the Web front-end. A team area is also created for the Project Management Committee (PMC), which is the team in charge of the project management of the whole project. This team provides approval for certain work items.

Figure 2. Permissions for PMC members include an approval option
Permissions configuration view

Larger view of Figure 2.

Given that the shell of Rational Team Concert can be shared with other Rational products, mainframe developers can use Rational Developer for System z and Rational Team Concert for System z to develop and share COBOL and other types of source code that they use on the mainframe. Similarly, the Web developers can use IBM® Rational® Application Developer and Rational Team Concert to develop and share Java™ and Web service sources. A developer can also use all three products in a single development environment to develop both the mainframe applications and Web services.


The source code and other artifacts required for this article are grouped into these four components:

  • Mainframe Application component is owned by the Mainframe Dev Team and contains the COBOL source files of the CICS application in multiple Rational Team Concert zComponent projects.
  • Mainframe Common Files component is owned by the Mainframe Dev Team and contains the common copybooks, which are required by the CICS application.
  • Web Service Files component is owned by the Mainframe Dev Team and contains the Web Services Description Language (WSDL) and WSBind files for the CICS Web service. This component is also required by the Distributed Dev Team to develop the Web front-end applications.
  • Web Application component is owned by the Distributed Dev Team and contains Web projects that consist of Web and EAR projects for the Web front end.

Streams and flow

As discussed earlier, there will be five streams, plus the production stream. They are arranged in the hierarchical library structure, which is typically used for mainframe application development.

  • Mainframe Dev Stream is owned by the Mainframe Development Team, so the mainframe developers deliver their change sets to this stream. This stream contains these components:
    • Mainframe Application
    • Mainframe Common Files
    • Web Service Files
  • Distributed Dev Stream is owned by the Distributed Development Team. This stream contains the Web Service Files and Web Application components.
    Note: The Web Service Files component is present in the two development streams, but is owned by the Mainframe Dev Team. The distributed developers deliver their change sets into this stream.
  • Dev Integration Stream is used to integrate both the mainframe and distributed applications to build a complete, cross-platform mortgage payment application. This stream is owned by the project area that members of both teams belong to. This stream contains components that exist in both the Mainframe Dev Stream and Distributed Dev Stream.
  • Test Stream is used for promotion. It is the target stream for the changes promoted from the Dev Integration Stream. Promotion is done by replacing the components from this stream with the baselines in the Dev Integration Stream. This stream is available in the project area for either team.
  • QA Stream is also a promotional stream, but used for quality assurance purposes. The components from the Test Stream are promoted to this stream. The promotion is also done by replacing components in this stream with the baselines from the Test Stream.

Finally, a production stream tracks the source that is deployed to production (not shown on the diagram).

The diagram in Figure 3 illustrates the streams and the flows used in this example.

Figure 3. Streams and flows used in this example.
Flow diagram of the streams

Data Set Definitions, Translators, and Language Definitions

Data Set Definitions, Translator and Language Definition are IBM® Jazz™ model objects used for Rational Team Concert Ant with extensions for z/OS build (also referred to as Antz), which is a build type supported by Rational Team Concert for building mainframe applications. In order to perform an Antz build successfully, they need to be configured properly.

In this example, DD name/concatenations need to be defined differently in Translators depending on the streams.

For example, the Test Stream is using CICS Version 4.1 while Dev Integration Stream is using CICS Version 3.2, a different DD concatenation needs to be specified for SYSLIB. For dealing with such situations, Rational Team Concert allows build administrators include build properties in DD names/concatenations. Those build properties are given values, which refer to Data Set Definitions, in Build Definitions.

Figure 4. Use of a Build Property in SYSLIB Concatenation
Edit DD concatenation page

Another requirement in this example is that host files have to be loaded in different data sets depending on the streams at build time.

Rational Team Concert defines a special Eclipse project type called zComponent project for mainframe applications. zComponent can contain one or more folders called zFolders. A zFolder is associated with a Data Set Definition in order to references a PDSE data set on z/OS system. A zFolder can contain one or more files called zFiles. When a zFile needs to be built by an Antz build, it is associated with a Language Definition.

Figure 5. zProject, zFolder, and zFile
Structure of a zProject

In an example shown in Figure 5, the MortgageApplication-EPSCMORT zProject contains a BMS zFolder, which has an zFile. When this project is loaded from Jazz SCM, a member whose name EPSMORT is created in a data set, which has the characteristics defined in the Data Set Definition, which is associated with the zFolder BMS.

Because the MortgageApplication-EPSCMORT zProject is contained in different streams, the zFile has to be loaded in different data sets depending on stream. It is done by using the data set prefix build property defined in build definitions created by the Antz build definition template.

Figure 6. Data set prefix in Antz build definition
Data set prefix field shows HLQ.INTG

Larger view of Figure 6.

For example, if the build definition for Test Stream defines the data set prefix build property to HLQ.TEST, and the one for the Dev Integration Stream defines the data set prefix build property to HLQ.INTG, the zFile is loaded as the member EPSMORT in both the HLQ.TEST.BMS data set for the Test Stream and in the HLQ.INTG.BMS data set for the Dev Integration stream, respectively, when the build occurs.

Build definitions

Each stream has a repository workspace defined specifically for use when building the stream.

The Mainframe Dev Stream Build is defined using the "Antz – Rational Build Agent" build definition template.

When a zComponent project is created in the Rational Team Concert Eclipse client, a default Antz build script (build.xml) is automatically created. For this example, the build script used for the Mainframe Dev Stream Build is modified from the default to add more tasks and targets to provide additional build order information to the Antz runtime code. The example in code Listing 1 specifies that BMS maps must be processed before COBOL compilation.

Listing 1. Build script for the Mainframe Dev Stream Build
        <antz:langdefselector name="BMS"/>
            <antz:langdefselector name="COBOL*"/>

Because the build script used for the Antz build is an Ant build file, standard Ant tasks and data types can be used in addition to build extensions provided by Antz.

For example, in the mortgage application, some SQL statements are embedded in COBOL source code, which requires that the DB2 BIND PACKAGE command be run. This can be done by either a standard Apache Ant exec task or, as Listing 2 shows, with a REXX script being called from the Antz build script through the use of the z/OS UNIX® TSO shell command.

Listing 2. DB2 bind package command
<!-- Macro definition for DB2 BIND PACKAGE command -->
<macrodef name="db2BindPackage">
    <attribute name="system"/>
    <attribute name="package"/>
    <attribute name="library"/>
    <attribute name="member"/>
    <attribute name="owner"/>
    <attribute name="qualifier"/>
    <attribute name="action"/>
    <attribute name="isolation"/>
        <exec executable="tso" failonerror="true">
            <arg line="&quot;EXEC 'TAMI.JAZZ.EXEC(PACKBIND)' 
                '@{system} @{package} @{library} @{member} @{owner} @{qualifier} 
                   @{action} @{isolation}'&quot;"/>


The Distributed Dev Stream Build uses the IBM® Rational® Application Developer for WebSphere® Software Build Utility (BU). You can use the BU to build Rational Application Developer projects without using the Eclipse IDE environment. There are versions of the BU for Microsoft® Windows®, Linux®, and IBM® z/OS® platforms. In this example, we use a z/OS version.

The build utility provides another set of Apache Ant extensions. In this example, the Distributed Dev Stream build is defined by using an Antz build definition and uses two Ant build scripts. One is for Antz, and another is for the BU. The first one is specified in the build definition and invokes the shell script, specifying the second build script in a command argument to perform the build by using the BU.

Listing 3. Build of the J2EE application
<exec executable="${bu.installDir}/eclipse/bin/" 
    <arg value="-buildfile"/>
    <arg value="${basedir}/build.xml"/>
    <arg value="all"/>
    <env key="workspace" value="${teamz.scm.fetchDestination}"/>

The Dev Integration Stream Build simply combines the Mainframe Dev Stream Build and the Distributed Dev Stream Build (see Listing 3). You define it by using the Antz build definition template. This definition performs the mainframe application build first and invokes the build script for the BU.

Listing 4. Code for the Dev Integration Stream Build
<!-- Invoke distributed build -->
<target name="distributed" description="Distributed build">
    <ant antfile="${teamz.scm.fetchDestination}/Automation/automation.xml"/>

The Test Stream Build and the QA Stream Build are defined in the same way as the Dev Integration Stream Build, with different targets for deployment.


The team has just released a major version of the application. The requirements for the next release of the application are being reviewed. For this scenario, you will focus on just one specific requirement:

A down payment field must be added to a copybook and taken into account in the calculation of the mortgage.

To preserve compatibility with the current version of the new service, you will create a new operation and add the down payment field to the input message.

This change affects the logic of the mainframe application: it must implement a new method of calculation of the monthly payment to account for this new field. This also requires a change in the data structure that is exposed in the Web services and used by the Web client.

Let's see how the team handle this change that implements a new contract between the client and server applications and that requires synchronization between the two teams to be taken into account.

Ways to work with the Adoption item

The PMC team creates an Adoption work item in the project area. Adoption items are used to document the impact of changes, discuss the impact between teams, and schedule the adoption. The new Adoption item is visible from the dashboard (Figure 7); therefore, members of the team can address and comment on the work item.

Figure 7. The Mortgage Application dashboard highlights the Adoption item
Open Adoption list highlighted in the dashboard

For now, the work item is in the Proposed state. When the project leads decide that the item is to be included in the next release, the status will be change to Approved (see Figure 8).

Figure 8. Adoption work item shows approved by the PMC
Screen capture of Adoption Item 18 work item

Larger view of Figure 8.

New work items are created for both the Mainframe Dev Team and the Distributed Dev Team to address the adoption of the change. Approval records are updated in the work item to track the adoption of the new function by the affected teams.

Start the implementation of the new function

As part of maintaining the release code, a snapshot of the components in the integration stream has been taken. A snapshot is a process of creating a baseline of several components that are in sync in a stream.

The content of the integration stream has also been promoted to the Test and QA streams. Thus, the components in those three streams now have the same contents and baselines.

The development streams are also likely to be in sync with the integration stream. But they might contain new code that was not yet ready to be included in the previous release, so it has not been pushed to the integration stream yet. The development streams are either in sync with the component baselines of the integration stream or contain a few change sets that add to those baselines.

The WSDL is located in the Web Services Files Component. This component is owned by the Mainframe Dev Team and used by the Distributed Dev Team.

Figure 9 shows that the Distributed Dev Stream contains Baseline 5 of the Web Services Files component. This is the same baseline as in the Dev Integration Stream.

Figure 9. Component baselines in development streams
Web Services Files components highlighted in each

The Distributed Dev Stream is completely in sync with the integration stream. Notice that the Mainframe Dev Stream contains a different baseline of the Web Service Files component and of the Mainframe Application component. Therefore, the contents of the Mainframe Dev Stream might be ahead of what has been shared in the integration stream.

How to develop the new function

The plan items for the current iteration (Figure 10) reflect the work for the mainframe to do to implement the new requirement.

Figure 10. Plan items for the new requirement
Story and sub-tasks viewed in the Plan item

The mainframe team is the first one to implement the new function. They update the copybook and, by using Rational Developer Web service tools, they update the Web service files. Those changes create two change sets that are attached to the relevant work item and delivered to the Mainframe Dev Stream.

The mainframe team verifies that their build ran successfully. As a result of the build, new baselines are created for the components that had changes.

The development of the new function involves both teams. The mainframe team is responsible for providing the initial work in updating the copybook and Web service files.

At this stage, the mainframe team has completed their piece of the work. The Mainframe Dev Stream contains the new Web service files. The Distributed Dev Stream does not, and neither does the integration stream.

Figure 11 shows that the Mainframe Dev Stream contains Baseline 7 of the Web Services Files component, with the new developments. The Distributed Dev Stream and the Dev Integration stream still contain baseline 5 of the Web Services Files component.

Figure 11. Updated component baselines in the development streams
Mainframe Web Services Files entry shows a change

The mainframe team resolves their work item to notify the distributed team that the changes are ready for adoption. They also mark, in the approval record for the adoption item, that the change has been adopted by their team.

Figure 12. Work item approvals
Screen segment shows Approver and State

The mainframe team could now deliver the new Web service files to the integration stream. However, if they did that, the build at the integration level would fail, because the distributed team has not yet made the necessary changes to take into account the new Web service files. Therefore, they will wait until the Adoption item is adopted by both teams before delivering the updated files to the integration stream.

The Distributed Dev Team now needs to take into account the new Web service files. They have two options:

  • They could find the work items that have been resolved by the mainframe team and accept the attached change sets into their workspaces. This solution works well for small changes that need to be exchanged quickly between members of the team.
  • Or they could replace the current baseline of the Web Service Files component in the Distributed Dev Stream with the one that is present in the Mainframe Dev Stream. This solution works better in this case, because the team can get a consistent component that is available in their stream.

The team lead of the distributed team replaces the baseline of the Web service files component in their stream by editing the stream and use the "Replace With…" function to select the new baseline from the Mainframe Dev Stream. The Figure 13 illustrates the actions taken by the team lead.

Figure 13. Replacing a component baseline with another one
Replace component dialog in the Stream editor

Now, the distributed dev stream contains the new Web service files that have been produced by the mainframe team. The distributed team then makes necessary changes in their Web application to adopt the new down payment field. After they have successfully built and tested their code, they take a new snapshot of their stream. They also mark, in the approval record, that the change has been adopted.

The Adoption item has now been accepted by the two teams, so the PMC changes the state of the item to Completed. Both teams can now deliver their changes to the integration stream.

Figure 14. Completed adoption item
Checkmark beside 'Completed'

At this point, the integration stream should have the changes from both of the teams. The weekly build that is scheduled to validate the integration of the changes from the two teams will run successfully.


As part of the software development life-cycle, code is promoted through various stages of product development. After the changes are successfully built in the weekly build, the teams can verify the outputs.

When they are satisfied with the new function in the development integration stream, they notify the test team lead. The test lead then replaces all of the components in the Test Stream with the baselines from the development integration stream. At this level, the testers can begin testing the latest release of the product. If they discover a defect, they create a new work item to track the fix for the defect and assign it to the appropriate team.

The teams then have to follow the same process to collaborate on the fix and deliver it to the development Dev Integration stream. Eventually, a new snapshot containing the fix is created and promoted to the Test Stream.

The testers then re-do the testing. When they are satisfied with the release, they follow the same process to promote the code from the Test stream to the QA stream. At that stage, the product is ready to be verified to ensure the requirements are met.


This article demonstrated how IBM Rational Team Concert for System z can satisfy the needs of cross-platform application development, which includes both mainframe and distributed pieces. Through the example of a change in contract to implement a new function, you have seen how two sub-teams can plan, collaborate, and implement the new function by sharing the new contract at sub-team level first and then integrating it when both sub-teams have completed their work.

Review the Resources section that follows for more information about these and other features not covered in this article.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

Zone=Rational, DevOps
ArticleTitle=Using IBM Rational Team Concert for System z and the Jazz platform: Part 4. How cross-system development with Rational Team Concert for System z works