Multiple Code Pipeline Instances on an LPAR
This section discusses the various issues that can be encountered when running multiple copies of Code Pipeline on the same LPAR—and how to resolve them. The focus is on running two copies of Code Pipeline, because the issues are similar regardless of how many additional instances are involved.
First, two scenarios are presented:
- the two Code Pipelines are the same version (for example, 22.01)
- the two Code Pipelines are different versions (for example, 22.01 and 18.02)
Then the use of configuration entries and the WZZRCCNF table are discussed for the two scenarios.
Finally, the sharing of SITE data sets between Code Pipeline instances is discussed and recommendations are presented.
Overview
Assume that the two Code Pipeline systems are called PROD and TEST. PROD is the production system used to do regular development work. TEST is a test system used to test various changes such as site customizations, fixes, new versions, etc.
The following six items covered in the subsequent scenarios, must be considered:
- Code Pipeline system data sets (load libraries, panels, etc.). For this discussion, they will be referred to as BASE data sets.
- Code Pipeline Started Task PROCLIB members (CM, CI, CT, SX, RX, and FX). For this discussion, they will be referred to as STCs.
- Code Pipeline SITE data sets (local customizations).
- Db2
- Lifecycle data sets
- Runtime configuration (WZZRC plus its aliases and the configuration table WZZRCCNF)
z/OS Linklist
We do not recommend that the BASE load libraries (SPWMLOAD and SPWMAUTH) be included in the z/OS linklist. It is recommended, however, that the runtime configuration load library (AUTHLINK) be included in the linklist. The runtime configuration executables and configuration table are upward- and downward-compatible between versions of Code Pipeline. This means the 22.01 version of these modules can be used to access a 18.02 system, and the 18.02 version of these modules can be used to access a 22.01 system. Therefore, you can include AUTHLINK in the linklist, even when running different versions of Code Pipeline.
Configuring the same and different Code Pipeline versions
When multiple Code Pipeline instances are run on the same LPAR, they can either be the same version, or one instance can be a newer version than the other. The six items mentioned above are discussed for each of those two scenarios.
PROD and TEST are the same version
In this scenario, the PROD and TEST instances of Code Pipeline are the same version, for example 22.01.
BASE data sets
Some customers use the same BASE data sets for PROD and TEST, while others use different BASE data sets (which would also have to be at the 22.01 level).
STCs
The STCs for PROD and TEST need to point to the appropriate BASE data sets, depending on whether they are the same for each Code Pipeline instance or different. For more information, see BASE data sets.
SITE data sets
Some customers use the same SITE data sets for PROD and TEST, and typically maintain them using the SITE application in the PROD system. Other customers choose to have separate SITE data sets and maintain them using the SITE applications in PROD and in TEST. For more information, see Configuring SITE data set Sharing.
Db2
PROD and TEST each need their own Db2 environment (tables, plans, etc.).
Lifecycle data sets
PROD and TEST each need their own lifecycle data sets.
Runtime configuration
The runtime configuration table WZZRCCNF can contain configuration entries for multiple Code Pipeline systems. The PROD entries must point to the appropriate PROD system SITE and BASE data sets, and the TEST entries must point to the appropriate TEST system SITE and BASE data sets, depending on the choices made for BASE data sets and SITE data sets above. For more information, see Working with Configuration Entries.
PROD and TEST are different versions
In this scenario, the PROD system is 18.02 and the TEST system is 22.01.
BASE data sets
PROD and TEST must use different BASE data sets: PROD must use 18.02 BASE data sets and TEST must use 22.01 BASE data sets.
STCs
The STCs for PROD and TEST need to point to the corresponding BASE data sets, 18.02 and 22.01 respectively.
SITE data sets
PROD and TEST must have different SITE data sets. During the installation of the 22.01 version of Code Pipeline, new SITE data sets are created. All local customizations to members in the 18.02 SITE data sets must be reviewed and merged into the same members after importing them into the 22.01 SITE data sets.
Db2
PROD and TEST each need their own Db2 environment (tables, plans, etc.).
Lifecycle data sets
PROD and TEST each need their own lifecycle data sets.
Runtime configuration
The runtime configuration table WZZRCCNF can contain configuration entries for multiple Code Pipeline systems. The PROD entries must point to the appropriate PROD system SITE and BASE data sets (18.02), and the TEST entries must point to the appropriate TEST system SITE and BASE data sets (22.01). For more information, see Working with Configuration Entries.
Working with configuration entries
A table of configuration entries, WZZRCCNF, is used to define various Code Pipeline interactions.
WZZRCCNF table (PROD and TEST are 22.01)
The WZZRCCNF table (in BPWMSAMP member WZZRCCNF) is a series of Assembler macros used to define multiple configuration entries. Those entries are used to select:
- appropriate SITE data sets and BASE data sets (for example, PROD or TEST)
- which Code Pipeline system to use (for example, PROD or TEST).
The SITE data sets are managed by the SITE application in the Code Pipeline system itself. This means there is a set of data sets for each of the three levels in the lifecycle: TEST, HOLD, and PROD.
Configuration entries
The sample distributed with Code Pipeline includes six configuration entries, defined by the WZZRCCON statements. This is only an example and is meant to provide you with a model you can use to create a suitable set of runtime configurations for your environment.
“Prod” configurations
Two of the configurations defined are considered “prod”: ISPP and ISPPHOLD.
- ISPP would be used to connect to the PROD system using the appropriate PROD system data sets, namely SITE.PROD and BASE. This configuration would normally be used by end users.
- ISPPHOLD would be used to connect to the PROD system using the appropriate PROD system data sets, namely SITE.HOLD and SITE.PROD and BASE. This allows for testing of updates to SITE members by promoting them from TEST to HOLD. Once everything looks good with the updates, they would then be promoted to PROD. This configuration might be used by administrators to verify changes are correct, or possibly by a select group of end users.
The SRID parameter on the two WZZRCCON statements must match the SERVERID of the PROD system, and the CMID parameter must match the XMEMID of the PROD CI that connects to the PROD CM.
“Test” configurations
The remaining four configurations defined are considered “test”: ISPT, ISPTHOLD, ISPTTEST, and ISPTTRCE.
- ISPT would be used to connect to the TEST system using the appropriate TEST system data sets, namely SITE.PROD and BASE. This configuration would normally be used by those testing various changes to Code Pipeline, including PTFs.
- ISPTHOLD would be used to connect to the TEST system using the appropriate TEST system data sets, namely SITE.HOLD and SITE.PROD and BASE. This configuration would normally be used by those testing various changes, including SITE changes.
- ISPTTEST would be used to connect to the TEST system using the appropriate TEST system data sets, namely SITE.TEST and SITE.HOLD and SITE.PROD and BASE. This configuration would normally be used by those performing early testing of SITE changes.
- ISPTTRCE is meant to demonstrate how to set up default client tracing when used to connect to the TEST system.
The SRID parameter on the four WZZRCCON statements must match the SERVERID of the TEST system, and the CMID parameter must match the XMEMID of the TEST CI that connects to the TEST CM.
Compiling and Linking WZZRCCNF
Member $WZB4CNF contains JCL that can be used to compile and link the WZZRCCNF member.
WZZRCCNF table (PROD is 18.02, TEST is 22.01)
When Code Pipeline 22.01 is installed, a new set of SITE data sets is created. After installing 22.01, there will be SITE data sets for 18.02 and SITE data sets for 22.01. The prefixes of the data set names are customer-specific and are specified during installation. The SITE data sets are managed by the SITE application in the Code Pipeline system itself. This means there is a set of data sets for each level in the lifecycle. There are three levels in the lifecycle: TEST, HOLD, and PROD.
This scenario is very similar to the one described above. The PROD configuration entries would point to 18.02 SITE and BASE data sets, and the TEST configuration entries would point to 22.01 SITE and BASE data sets.
The PROD system would be used for normal development work, while the TEST system would be used to test the new version of Code Pipeline.
Configuring SITE data set sharing
SITE data sets can be shared by more than one instance of Code Pipeline.
Sharing SITE data sets (PROD and TEST are 22.01)
In this configuration, sharing the SITE data sets between PROD and TEST makes sense. You could use the SITE application in the PROD system to make updates at the SITE.TEST level. You could then try them out using the TEST system (runtime configuration ISPTTEST). Then you could promote them to SITE.HOLD and test them using both the TEST system (runtime configuration ISPTHOLD) and PROD system (runtime configuration ISPPHOLD). Finally, you could promote them to SITE.PROD and use them in the TEST system (runtime configuration ISPT) and the PROD system (runtime configuration ISPP).
Sharing SITE data sets (PROD is 18.02, TEST is 22.01)
As mentioned above, the ISPF environments for 18.02 and 22.01 should function properly while sharing a single WZZRCxxx and WZZRCCNF, but only if all the BASE data sets are identified properly in different configuration entries. Correct entries will ensure that users get 18.02 Code Pipeline data sets when using the PROD system and get 22.01 Code Pipeline data sets when using the TEST system.
SITE data sets can present challenges when running 18.02 and 22.01 on the same LPAR. Although we strongly recommend not sharing SITE data sets between versions, it can be done—but only if all the original Code Pipeline members that are eventually customized are identical before customization. Some of the members that are often customized locally (for example, panels, skeletons, and CLISTs) may have changed, either between Code Pipeline versions or as a result of PTFs, and those changes must be addressed.
22.01 installation considerations
During the 22.01 installation process, you must specify the data set names for the 22.01 SITE data sets. Be sure to specify new names for them. Do not use the 18.02 data set names. BMC recommends you then install 22.01 up to the point where members are imported into the 22.01 SITE data sets.
You must then compare the appropriate 22.01 SPWMxxxx data sets to the equivalent 18.02 SPWMxxxx data sets. The appropriate data sets to compare are those containing members that have been imported into the 18.02 SITE data sets. These might include CLST, PENU, SKEL, MENU, and SAMP.
- Check the SPWMxxxx data sets carefully for changes to any members that have been imported into the 18.02 SITE data sets. If a member in the 18.02 SITE data sets is different in the two SPWMxxxx data sets:
- Use the new SITE data sets created for the 22.01 system.
- Import the appropriate members.
- Devise a way to carry forward the local changes from the members in the 18.02 SITE data sets to the same members in the 22.01 SITE data sets.
- If all the applicable members have not changed in the 18.02 and 22.01 SPWMxxxx data sets, you should be able to share the 18.02 SITE data sets when using the 22.01 system.