IBM Enterprise Platforms ExtensionsRational Team Concert includes support for IBM enterprise level platforms such as System z and the various operating systems that can run on the IBM Power platform such as IBM i, AIX and Linux on Power. This functionality is unlocked via the Developer for IBM Enterprise Platforms Client Access License and includes such things as :
Dependency Based Build
Building on the Ant based build technology in the Rational Team Concert for System z (RTCz) v188.8.131.52 and the Rational Team Concert for Power Systems Software (RTCp) v184.108.40.206 products, we have pushed the build boundaries out and enabled build to be smarter. Rational Team Concert is now aware of dependencies between buildable parts. For example, for z/OS applications, we now know what copybooks are included into a COBOL program. Armed with this information Dependency Based Build now knows what COBOL programs need to be rebuilt, or recompiled, when a copybook has been changed. The dependency information is obtained by scanning the source after it has been delivered into the repository. Rational Team Concert ships with a standard scanner that is able to understand COBOL and PLI. Similarly, in the case of IBM i applications, the Dependency Based Build understands RPG /COPY members, COBOL copybooks and dependencies on physical and logical files from RPG or COBOL source. The framework through which these scanners are registered is open to customers and so other scanners may be contributed for other languages.
For z/OS, this new Dependency Based Build is defined using a new Build Definition type.
For IBM i, the IBM i Build Specification build definition type (which was available in RTCp) can be used.
Dependency Based Build allows you to build everything, build the artifacts that the tooling decides needs to be built, or, in the case of z/OS, build a user defined set of artifacts.
Users are also able to tag a change set so that Dependency Based Builds will ignore the change (z/OS only).
We have also provided some tooling that further leverages the dependency information that the scanners have gathered.
A editor allows you to both view and manually modify the information gathered. This information is stored in an agnostic way so that any other metadata for an artifact can be stored in this fashion.
A query facility based on the work item query editor has also been provided allowing you to query across all metadata stored against a repository artifact, including the dependency metadata.
A common use of this dependency data that has been gathered is the ‘what if’ scenario….. What would happen if I changed this copybook? Because this is such a common use of this data we have created a first class wizard to walk through and provide the answer to this question. For z/OS, we also pushed this wizard a little further and if you give us a build definition we are able to answer this question with build time accuracy since we are able to resolve dependencies to actual physical artifacts because we are able to calculate the build path concatenation.
A very common practice in enterprise development shops is to have conceptual hierarchical levels of code. For example a Development, Quality, and Production level of code. The actual physical implementation of these hierarchical levels can vary. In a System z shop a common implementation is to have a different set of Partitioned Data Sets (PDS) for each hierarchical level, each with a different high level qualifier. Rational Team Concert now includes tooling that supports promotion for code up these conceptual hierarchies. Rational Team Concert uses different streams for each hierarchical level. The tooling will automatically move source code from one stream to another and will also copy the build output on the target system from one data set to another data set. It will then tweak the Dependency Build metadata so that Dependency Based Build does not think it needs to rebuild anything.
Another common operation in development organizations is to deploy runtime code to different runtime platforms. Rational Team Concert now has support for this. The tooling allows you to define packages of build output that must be deployed. A Package Definition describes what is to be deployed.
A Deployment Definition allows you to describe where a package is to be deployed to.
Context-aware search enables you to search with natural language rather than exact patterns.
This capability allows analysis of a work item for relevant keywords. Using keywords, the search locates source code that may be relevant for the work item, which saves you time and provides another valuable way to assess the impact and scope of a change.