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.

Context

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.

Back to top

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

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.

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.

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.

Components

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.

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.

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.

In an example shown in Figure 5, the MortgageApplication-EPSCMORT zProject contains a BMS zFolder, which has an EPSMORT.bms 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 EPSMORT.bms 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.

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 EPSMORT.bms 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.

<antz:compile>
    <restrict>
        <antz:buildableset 
            buildableList="${teamz.scm.fetchDestination}/buildableFiles.xml"/>
        <antz:langdefselector name="BMS"/>
    </restrict>
</antz:compile>
<antz:compile>
    <restrict>
        <antz:buildableset 
            buildableList="${teamz.scm.fetchDestination}/buildableFiles.xml"/>
        <rsel:or>
            <antz:langdefselector name="COBOL*"/>
        </rsel:or>
    </restrict>
</antz:compile>

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.

<!-- 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"/>
    <sequential>
        <exec executable="tso" failonerror="true">
            <arg line="&quot;EXEC 'TAMI.JAZZ.EXEC(PACKBIND)' 
                '@{system} @{package} @{library} @{member} @{owner} @{qualifier} 
                   @{action} @{isolation}'&quot;"/>
        </exec>
    </sequential>
</macrodef>


<db2BindPackage
           system="DSN9"
           package="DEV2"
           library="${teamz.scm.dataset.prefix}.DBRM"
           member="EPSCMORT"
           owner="DEVDBA"
           qualifier="DEVDBA"
           action="REPLACE"
           isolation="CS"/>

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 runAnt_zos.sh shell script, specifying the second build script in a command argument to perform the build by using the BU.

<exec executable="${bu.installDir}/eclipse/bin/runAnt_zos.sh" 
    failonerror="true">
    <arg value="-buildfile"/>
    <arg value="${basedir}/build.xml"/>
    <arg value="all"/>
    <env key="workspace" value="${teamz.scm.fetchDestination}"/>
</exec>

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.

<!-- Invoke distributed build -->
<target name="distributed" description="Distributed build">
    <ant antfile="${teamz.scm.fetchDestination}/Automation/automation.xml"/>
</target>

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.

Back to top

Scenario

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.

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).

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.

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.

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.

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.

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.

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.

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.

Back to top

Promotion

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.

Back to top

Summary

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.

Resources

Learn

• To catch up on Jazz technology, make Jazz.net your first stop. You can also watch the IBM Jazz channel on YouTube.
  
  
• For Rational Team Concert:
  • Check the Rational Team Concert for System z product page, but be sure to explore the Rational Team Concert developerWorks portal to learn about the other versions available.
  • Documentation is in the Rational Team Concert for System z Information Center.
  
  
• For Rational Developer for System z:
  • Visit the product page and the community hub at the Rational Café, as well as the developerWorks page.
  • Read through the Information Center, and explore the Rational Developer for System z plug-in for the IBM Education assistant
  
  
• Learn about other applications in the IBM Rational Software Delivery Platform, including collaboration tools for parallel development and geographically dispersed teams, plus specialized software for architecture management, asset management, change and release management, integrated requirements management, process and portfolio management, and quality management. You can find product manuals, installation guides, and other documentation in the IBM Rational Online Documentation Center.
  
  
• Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
  
  
• Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Some of the "Getting Started" courses are available free of charge.
  
  
• Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
  
  

Get products and technologies

• Download a free trial version of Rational Team Concert for System z or any of the Rational Team Concert versions.
  
  
• Download a free trial of Rational Developer for System z.
  
  
• Download trial versions of other IBM Rational software.
  
  
• Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
  
  

Discuss

• Ask and answer technical questions and exchange information with your peers in the Rational Developer for System z forum.
  
  
• Check out the Jazz forums, too.
  
  

About the authors

Nicolas 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 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 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.

Rate this article

Comments

Back to top

Table of contents

• Context
• Set up components and streams
• Scenario
• Promotion
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: Rational Team Concert
• Demo: Rational and Jazz
• Webcast: Agile development with IBM Rational Synergy and IBM Rational Team Concert
• Buy: Rational Team Concert

Dig deeper into Rational on developerWorks

Try IBM PureSystems. No charge.

Experience today!

---

Get started with the cloud-based trial and pattern development kit.

Special offers