Overview
With this blog, we will briefly touch on the exciting new enhancements in IBM Z Monitoring Configuration Manager that have been delivered with PTF UJ92421 (APAR OA64052) in Q1 2023.
The following items will be discussed:
- New KCIVARS OPTION parameter
- New MIGRATE action features
- High-level Qualifier length limit extension
New KCIVARS OPTION parameter
Listening to our customers is very important for us. There has been feedback from the field stating that some of the actions Configuration Manager provides, especially the GENERATE action, are seen as too monolithic in certain environments or for certain configuration use cases.
The new OPTION parameter in KCIVARS will alleviate this issue by introducing new option keywords that will drive the related ACTION accordingly. The newly introduced parameter will also make it possible to add new keywords going forward.
With the Q1 PTF, the option keywords USS, NOUSS and SECEXITS have been delivered for action GENERATE. Here is an example of how the OPTION parameter with keyword USS can be used for a GENERATE action:
//UID#ZMCM JOB ,CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
...
//KCIVARS DD *
*
ACTION GENERATE
OPTION USS
RTE_NAME RTE1
RTE_PLIB_HILEV TSOUID.MONSUITE
/*
The GENERATE action options USS and NOUSS allow you to drive (or skip) the specific workflow stage that deploys the z/OS® UNIX System Services related parts. This will be useful if you have environments where you want to deploy/generate these parts only once, as they are referenced in a shared fashion by other Runtime Environments (RTEs).
Also, if you have users that need special privileges to run the z/OS® UNIX System Services related workflow stage, this can be done by running the action GENERATE with option keyword USS.
The GENERATE action option keyword SECEXITS allows you to rebuild the security exit members (load modules) only.
Furthermore, option keyword MULTIPLE is delivered for action MIGRATE. As this is a very significant enhancement, we want to reserve a separate section on this, so read on!
New MIGRATE action features
Level set
As a reminder, the MIGRATE action imports configuration settings from a runtime environment that is configured with PARMGEN to one that is configured with Configuration Manager. Here is a typical MIGRATE action JCL example:
//UID#ZMCM JOB ,CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
...
//KCIVARS DD *
*
ACTION MIGRATE
RTE_NAME RTE1
RTE_PLIB_HILEV TSOUID.MONSUITE
KFJ_MIGRATE_WCONFIG PARMGEN.HLQ.WCONFIG
/*
The purpose of the MIGRATE action is to create the respective configuration data sets needed by Configuration Manager to manage the RTE configuration; these are primarily the RTEDEF and SECEXITS data sets.
You will run the MIGRATE action by referencing the PARMGEN RTE name in the RTE_NAME parameter and the PARMGEN WCONFIG data set containing the PARMGEN configuration settings and RTE name member using parameter KFJ_MIGRATE_WCONFIG.
In-place PARMGEN migrate support
Previously, it was only possible to run the MIGRATE action by referencing a different high-level-qualifier (HLQ) in parameter RTE_PLIB_HILEV than what is used in the referenced PARMGEN WCONFIG. Using the same HLQ caused the migration action run to fail.
With UJ92421, you can use the same HLQ that PARMGEN uses in your MIGRATE run, which is referred to as an in-place migrate.
This does not require you to establish a new set of HLQs (for example, for VSAM and non-VSAM data sets), but instead allows you to reuse the HLQs that were set up to be used by PARMGEN.
After a successful run of the in-place MIGRATE, you will get the PARMGEN configuration settings encapsulated in the respective RTEDEF and SECEXITS data sets (and EMBEDS data sets, if requested).
Note: Before you run the GENERATE action, it is recommended that you take a backup of the RTE libraries and PARMGEN data sets as the GENERATE action run will replace the existing data sets.
Multi-migrate support
With UJ92421, you can now migrate multiple runtime environments into a single RTEDEF data set, which is referred to as a multi migrate.
Multi-migrate support lifts a significant restriction, where every MIGRATE action run had to have a distinct RTEDEF data set associated with it, and all the members within the RTEDEF data set had the SYSPLEX scope suffix of "PARM".
A manual consolidation of multiple RTE configurations into a single RTEDEF data set was quite cumbersome. Such a consolidation makes very much sense: the scope of the RTEDEF data set is the SYSPLEX, so consolidating all LPAR configurations for a SYSPLEX into a single RTEDEF data set is a good idea to keep the configuration compact.
The following sample JCL shows how to use the multi-migrate feature:
//UID#ZMCM JOB ,CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
...
*
ACTION MIGRATE
OPTION MULTIPLE
RTE_NAME RTE1
RTE_PLIB_HILEV TSOUID.MONSUITE
KFJ_MIGRATE_WCONFIG highlevel.WCONFIG
KFJ_SYSNAME SYSA
/*
As you can see, we make use of the new OPTION parameter (described earlier in this article). The keyword MULTIPLE (short form MULTI) directs the MIGRATE action to use the LPAR-specific suffix specified in KFJ_SYSNAME (SYSA in the example above) to create the respective configuration members.
You can run the same JCL several times by specifying different values for RTE_NAME / KFJ_SYSNAME pairs and with the same KFJ_MIGRATE_WCONFIG, if RTEs are kept in the same WCONFIG data set in PARMGEN. This will result in the respective RTEDEF data set populated with the configuration members.
If you have the PARMGEN configurations for a SYSPLEX spread out to multiple WCONFIG data sets, you have to use the respective values in parameter KFJ_MIGRATE_WCONFIG to consolidate the configurations into a single RTEDEF data set with high-level-qualifier as specified with parameter RTE_PLIB_HILEV.
The following example shows the output of three MIGRATE action runs with different settings for RTE_NAME / KFJ_SYSNAME pairs where the same referenced PARMGEN WCONFIG data set contains multiple RTE definitions:
High-level-qualifier length limit extension
Previously, there was a limitation of 20 characters for the value represented by the RTE_PLIB_HILEV.RTE_NAME concatenation.
This restriction did not allow a lot of flexibility when defining new RTEs and also caused issues when migrating RTEs from PARMGEN using the MIGRATE action.
With UJ92421, this limitation is lifted and you can now use concatenated HLQ values up to 28 characters in length.
Documentation
For more detailed information on the OPTION parameter, refer to the respective chapter in the OMEGAMON Shared documentation.
For more information about the usage of the OPTION parameter keywords, refer to the GENERATE and MIGRATE documentation.
#ZAIOPS #OMEGAMON #IBMZ