Introduction

The evolution of IBM Z Monitoring Configuration Manager continues!

With PTF UJ06499/APAR OA61601, IBM Z Monitoring Configuration Manager enables customers to generate their Runtime Environment (RTE) on a local z/OS system and package the RTE data sets into a well-defined number of DUMP data sets (with a new PACKAGE action). Customers will transfer these packages to a remote target system (via FTP or Tape), which can potentially reside on a different SYSPLEX, and then RESTORE the RTE DUMP files on this system (with a new DEPLOY action).

The following information about the new enhancement is intended to give an overview of this new function. Refer to the Configuration Manager documentation for all details.

Centralized Configuration

User Story "Centralized Configuration"

As a Configuration Manager user, I want to be provided with an easy-to-use way to locally generate my runtime environments on a single system, without the need to run any of the actions on the target LPAR (Exception: DISCOVER action).

In order to implement the centralized configuration user story, the following changes to existing Configuration Manager actions are necessary:

DISCOVER action extensions
The DISCOVER action can be run in a standalone fashion, thus not relying on a previous CREATE action anymore.
The intention is to run the DISCOVER action on the target z/OS® system and transfer the produced RTEDEF data set contents to the central system used to generate the runtime environments.
In addition, the DISCOVER action creates a new additional member RTEDEF(SYS@lpar) that contains all the system symbols and variables required to perform the local GENERATE and as such to reflect the target system environment properly.
To support the standalone DISCOVER (and DEPLOY) actions on a remote system, a new utility option BLDREMDS is supported in the utility JCL TKANSAM(KFJMAINT) that will allow the user to prepare the necessary members in data sets TKANSAM, TKANCUS and TKANMOD. This utility is especially useful for those customers that have FULL RTEs , and not sharing with SMP/E (or SMP/E copies).

CREATE/MIGRATE action extensions
A new KCIVARS DD parameter KFJ_LOCAL_PLIB_HILEV is introduced that will enable customers to use a different high-level qualifier when generating the runtime environment locally.
Specifying this parameter will act as a “switch” and will trigger the creation of a new member RTEDEF(PCK$PARM) that allows for a local mapping of high-level qualifiers and z/OS Unix System Services directories to be used (Note: RTEDEF(PCK$lpar) is also supported to allow for LPAR specific mappings).
The new parameter is also used in the changes for the GENERATE action.

Extension to GENERATE action
The GENERATE action will honor the new KCIVARS DD input parameter KFJ_LOCAL_PLIB_HILEV along with RTEDEF(PCK$PARM) to generate the runtime environment on the local configuration system.  
KFJ_LOCAL_PLIB_HILEV should be used only if you intend to use different data set high level qualifiers or z/OS Unix system services paths for the configuration system and target system respectively.

PACKAGE and DEPLOY

User Story "Package and Deploy"

As a Configuration Manager user, I want to be able to package my locally generated runtime environments and deploy them to a different SYSPLEX.

In order to implement the user story for packaging and deploying an RTE, the following additional actions have been implemented:

PACKAGE action
A new PACKAGE action will take the generated runtime environment data sets and save them into a series of package (or DUMP) data sets than can then be transferred to the target system, for example using FTP or (virtual) Tapes.
The packages are split between VSAM and non-VSAM data sets and main product and history related data sets. There is a maximum of five DUMP data sets created using the following naming convention:
rPlibHilev.rte_name.PACK<xx>[.DMP] where <xx> is package “code”:

• MN - main non-VSAM package. Contains data sets from RTE_HILEV and some from RTE_PLIB_HILEV
• MV - main VSAM package. Contains non-history related VSAM data sets from RTE_VSAM_HILEV
• HN - history non-VSAM package. Contains history related data sets from RTE_PDS_HILEV
• HV - history VSAM package. Contains history related data sets from RTE_VSAM_HILEV
• MD - package meta data - this is a flat file, NOT tersed or dumped - it is required for DEPLOY action if data set rename is desired.

The PACKAGE action has additional parameters to allow for specifying a high-level qualifier for the DUMP data sets, handling a terse of the packages or support non-SMS environments.
Large package files will be supported by allowing the specification of an SMS data class.

DEPLOY action
A new DEPLOY action has been added that will be executed on the target system and will restore the packages transferred.
If you decide to deploy using different high-level qualifiers, the DEPLOY action will now honor the parameters for high level qualifiers and z/OS Unix system services path from the RTEDEF members and not the ones from RTEDEF(PCK$PARM). In fact, the parameter KFJ_LOCAL_PLIB_HILEV is ignored by the DEPLOY action.

The DEPLOY action replaces all target main VSAM and non-VSAM data sets but does not replace any history-related data sets (a warning return code is returned in that case).
In case of a maintenance rollout, a partial list of packages is supported. That is a warning that will be produced in the KCIPRINT DD of the Configuration Manager Batch job, when no history related packages are found (<xx> is “HV” and “HN”).

Important: In case you are using different high-level qualifiers for source and target LPARs, that is when the parameter KFJ_LOCAL_PLIB_HILEV  is used, make sure the “MD” meta data package is transferred properly.

Sample deployment scenario

In a remote deployment scenario, you must create a runtime environment on a specific LPAR (called the Configuration LPAR or CL), package the runtime environment data sets using the PACKAGE action, transfer the data sets to the remote target system (called the “Target LPAR” or TL), and deploy/restore the packaged runtime environment data sets on the Target LPAR using the DEPLOY action. The following picture illustrates the steps needed in this process:

Referring to the steps in the illustration:

• (1) CL: CREATE initial RTEDEF file (consider different local HLQs)
• (2) TL: Run the DISCOVER action on the remote lpar (assume SMP/E clone, or subset of libs available)
  This will produce SYS@lpar file along with other discovery members in RTEDEF file
• (2’) CL: Transfer RTEDEF created on remote LPAR (called RTEDEF2 in illustration) to CL and merge with existing RETDEF (i.e. “copy into it”)
• (3) CL: Customize your RTE at your needs (consider different local HLQs in RTEDEF(PCK$PARM))
• (4) CL: Run GENERATE action for the RTE for your remote lpar using KFJ_SYSNAME=lpar in KCIVARS DD
• (5) CL: Run PACKAGE action to build transferable (tersed) packages data sets
• (6) CL: Transfer (tersed) packages to remote LPAR (6’)
• (7) TL: Run DEPLOY action on remote LPAR to unpack/restore the (tersed) package data sets
• TL: If applicable/needed, adjust/copy your STC procs

Conclusion

The Centralized Configuration Management feature provides a complete process to configure and deploy OMEGAMON with IBM Z Monitoring Configuration Manager and goes far beyond what is available in PARMGEN today.
The capability to generate RTEs from a centralized system adds simplicity and enables customers to minimize downtime when deploying to production systems.

Documentation

The IBM Z Monitoring Configuration Manager documentation now reflects the additional options delivered with enhancement PTF UJ06499/APAR OA61601.

For more details:

• What’s new: Link
• PACKAGE Action: Link
• DEPLOY action: Link
• Remote Deployment Scenario – an example: Link