Multiple ISPW Instances on an LPAR

This section discusses the various issues that can be encountered when running multiple copies of ISPW on the same LPAR—and how to resolve them. The focus is on running two copies of ISPW, because the issues are similar regardless of how many additional instances are involved.

First, two scenarios are presented:

  • the two ISPWs are the same version (for example, 17.02)
  • the two ISPWs are different versions (for example, 17.02 and 18.02).

Then the use of configuration entries and the WZZRCCNF table are discussed for the two scenarios.

Finally, the sharing of SITE datasets between ISPW instances is discussed and recommendations are presented.

Overview

Assume that the two ISPW 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:

  • ISPW system datasets (load libraries, panels, etc.). For this discussion, they will be referred to as BASE datasets.
  • ISPW Started Task PROCLIB members (CM, CI, CT, SX, RX, and FX). For this discussion, they will be referred to as STCs.
  • ISPW SITE datasets (local customizations).
  • Db2.
  • Lifecycle datasets.
  • Runtime configuration (WZZRC plus its aliases and the configuration table WZZRCCNF).

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 ISPW. This means the 18.02 version of these modules can be used to access a 17.02 system, and the 17.02 version of these modules can be used to access an 18.02 system. Therefore, you can include AUTHLINK in the linklist, even when running different versions of ISPW.

Configuring the Same and Different ISPW Versions

When multiple ISPW 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 ISPW are the same version, for example 17.02.

BASE Datasets

Some customers use the same BASE datasets for PROD and TEST, while others use different BASE datasets (which would also have to be at the 17.02 level).

Important

To test ISPW PTFs using TEST, you would need to use different BASE datasets. You would apply the PTF to the TEST BASE datasets first, then subsequently apply it to the PROD BASE datasets.

STCs

The STCs for PROD and TEST need to point to the appropriate BASE datasets, depending on whether they are the same for each ISPW instance or different. For more information, see BASE Datasets.

SITE Datasets

Some customers use the same SITE datasets for PROD and TEST, and typically maintain them using the SITE application in the PROD system. Other customers choose to have separate SITE datasets and maintain them using the SITE applications in PROD and in TEST. For more information, see Configuring SITE Dataset Sharing.

Db2

PROD and TEST each need their own Db2 environment (tables, plans, etc.).

Lifecycle Datasets

PROD and TEST each need their own lifecycle datasets.

Runtime Configuration

The runtime configuration table WZZRCCNF can contain configuration entries for multiple ISPW systems. The PROD entries must point to the appropriate PROD system SITE and BASE datasets, and the TEST entries must point to the appropriate TEST system SITE and BASE datasets, depending on the choices made for BASE Datasets and SITE Datasets above. For more information, see Working with Configuration Entries.

PROD and TEST are Different Versions

In this scenario, the PROD system is 17.02 and the TEST system is 18.02.

BASE Datasets

PROD and TEST must use different BASE datasets: PROD must use 17.02 BASE datasets and TEST must use 18.02 BASE datasets.

STCs

The STCs for PROD and TEST need to point to the corresponding BASE datasets, 17.02 and 18.02 respectively.

SITE Datasets

PROD and TEST must have different SITE datasets. During the installation of the 18.02 version of ISPW, new SITE datasets are created. All local customizations to members in the 17.02 SITE datasets must be reviewed and merged into the same members after importing them into the 18.02 SITE datasets.

Db2

PROD and TEST each need their own Db2 environment (tables, plans, etc.).

Lifecycle Datasets

PROD and TEST each need their own lifecycle datasets.

Runtime Configuration

The runtime configuration table WZZRCCNF can contain configuration entries for multiple ISPW systems. The PROD entries must point to the appropriate PROD system SITE and BASE datasets (17.02), and the TEST entries must point to the appropriate TEST system SITE and BASE datasets (18.02). For more information, see Working with Configuration Entries.

Working with Configuration Entries

A table of configuration entries, WZZRCCNF, is used to define various ISPW interactions.

WZZRCCNF Table (PROD and TEST are 17.02)

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 datasets and BASE datasets (for example, PROD or TEST)
  • which ISPW system to use (for example, PROD or TEST).

The SITE datasets are managed by the SITE application in the ISPW system itself. This means there is a set of datasets for each of the three levels in the lifecycle: TEST, HOLD, and PROD.

Configuration Entries

The sample distributed with ISPW 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 datasets, 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 datasets, 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 datasets, namely SITE.PROD and BASE. This configuration would normally be used by those testing various changes to ISPW, including PTFs.
  • ISPTHOLD would be used to connect to the TEST system using the appropriate TEST system datasets, 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 datasets, 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 17.02, TEST is 18.02)

When ISPW 18.02 is installed, a new set of SITE datasets is created. After installing 18.02, there will be SITE datasets for 17.02 and SITE datasets for 18.02. The prefixes of the dataset names are customer-specific and are specified during installation. The SITE datasets are managed by the SITE application in the ISPW system itself. This means there is a set of datasets 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 17.02 SITE and BASE datasets, and the TEST configuration entries would point to 18.02 SITE and BASE datasets.

The PROD system would be used for normal development work, while the TEST system would be used to test the new version of ISPW.

Configuring SITE Dataset Sharing

SITE datasets can be shared by more than one instance of ISPW.

Sharing SITE Datasets (PROD and TEST are 17.02)

In this configuration, sharing the SITE datasets 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 Datasets (PROD is 17.02, TEST is 18.02)

As mentioned above, the ISPF environments for 17.02 and 18.02 should function properly while sharing a single WZZRCxxx and WZZRCCNF, but only if all the BASE datasets are identified properly in different configuration entries. Correct entries will ensure that users get 17.02 ISPW datasets when using the PROD system and get 18.02 ISPW datasets when using the TEST system.

SITE datasets can present challenges when running 17.02 and 18.02 on the same LPAR. Although we strongly recommend not sharing SITE datasets between versions, it can be done—but only if all the original ISPW 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 ISPW versions or as a result of PTFs, and those changes must be addressed.

18.02 Installation Considerations

During the 18.02 installation process, you must specify the dataset names for the 18.02 SITE datasets. Be sure to specify new names for them. Do not use the 17.02 dataset names. BMC suggests you then install 18.02 up to the point where members are imported into the 18.02 SITE datasets.

You must then compare the appropriate 18.02 SPWMxxxx datasets to the equivalent 17.02 SPWMxxxx datasets. The appropriate datasets to compare are those containing members that have been imported into the 17.02 SITE datasets. These might include CLST, PENU, SKEL, MENU, and SAMP.

  • Check the SPWMxxxx datasets carefully for changes to any members that have been imported into the 17.02 SITE datasets. If a member in the 17.02 SITE datasets is different in the two SPWMxxxx datasets:
    1. Use the new SITE datasets created for the 18.02 system.
    2.  Import the appropriate members.
    3. Devise a way to carry forward the local changes from the members in the 17.02 SITE datasets to the same members in the 18.02 SITE datasets.
  • If all the applicable members have not changed in the 17.02 and 18.02 SPWMxxxx datasets, you should be able to share the 17.02 SITE datasets when using the 18.02 system.

Important

Keep in mind that an appropriate member might be updated by a PTF, so even if sharing is possible at installation time, this could change in the future. Because members could be modified at any time, we strongly recommend not sharing the SITE datasets between versions of ISPW.


 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*