AIOps: Monitoring and Observability - Group home

With the release of the IBM Z Monitoring Configuration Manager Q2 2024 Enhancement PTF UJ95574 (APAR OA66051), we added significant updates on the customization of Thread Histories (Classic and e3270UI) in OMEGAMON for Db2 Performance Expert on z/OS 5.5.0.

If you use the OMEGAMON for Db2 agent, you know that to configure Classic Near-Term History VSAM data set allocation attributes, you modify the following parameters:

• KD2_PFnn_HIS_LOG_NUM to specify the number of classic thread history VSAM data sets to allocate
• KD2_PFnn_HIS_VSAM_VOLUME to specify which volume is used to store all thread history data sets
• KD2_PFnn_HIS_VSAM_SCLAS to specify which storage class is associated with the thread history VSAM data sets
• KD2_PFnn_HIS_VSAM_MCLAS to specify the management class for the stored thread history VSAM data sets

This means that each VSAM will be allocated with the same attributes. However, sometimes you may want to allocate them on different volumes. Before this update, it was not possible to do in configuration members only, whether it was updating WCONFIG in PARMGEN, or RTEDEF in Configuration Manager. Instead, you had to disable automatic allocation, which you do by setting KD2_OMPE_RUNALLOC to "N". Then, you had to update RKD2SAM(ALLOCDS) with your customized settings for the Near-term History VSAM data sets, and run the allocation job manually, once the RTE was regenerated. Then, you had to add this member to the EXCLUDE list, so that it would not be overwritten with each RTE update. The number of log files can range from 3 to 768, depending on the thread activity period you want to keep in history. That is potentially a lot of allocation statements to amend manually.

With the release of PTF UJ95574, this functionality was extended. Now, you can prepare all your VSAM data set customizations directly in the configuration. If you use Configuration Manager, now you can add as many parameters as you need directly in the KD5$lpar member, and if you use PARMGEN, you can add those parameters in your WCONFIG(rte_name) member. To turn this feature on, you need to be aware of the following new parameter:
   KD2_PFnn_HIS_VSAM_CUSTOMIZE

This is a flag-type parameter with only two available values – "Y" or "N". By default, customization is disabled, so if you need to set new allocation parameters, you must enable this flag (set it to "Y"). Then, the following parameters will be unlocked in v5.5.0:
   KD2_PFnn_HIS_VSAM_VOLUMEn
   KD2_PFnn_HIS_VSAM_SCLASn
   KD2_PFnn_HIS_VSAM_MCLASn

The "n" must range from 1 to the maximum log number you specified in parameter KD2_PFnn_HIS_LOG_NUM.

Keep in mind that the WCONFIG(rte_name) member already contains these parameters numbered 1-7, because they were used back in version 5.4.0. You can simply update them as needed, and configuration will pick up their values. Then add as many as you need, so it matches the value in KD2_PFnn_HIS_LOG_NUM. But, note that parameter KD2_PFnn_HIS_LOGn, which was used to specify the fully-qualified VSAM data set name in v5.4.0, will not be used in v5.5.0. Instead, we are introducing a parameter KD2_PFnn_HIS_VSAM_PREFIX, which will help you keep the v5.4.0 low-level-qualifier for backwards compatibility.

Enabling Near-Term history collection

Before you experiment with the new VSAM parameters, you need to enable the correct type of history collection. So, the following parameters are required as a prerequisite to the further examples that we will demonstrate:

In this case, a history store type parameter set to "VSAM" enables classic Near-Term history collection. This is the default option, so in Configuration Manager, if you are not enabling any other types of histories, you may leave your RTEDEF as is. You can have other types of histories enabled as well (see the last example). Also, it is important that you enable history collection with KD2_PF01_HIS_START option. 
Note that the KD2_OMPE_RUNALLOC flag is enabled by default so you do not have to specify it, but you can disable it (as follows) and run ALLOCDS job manually afterwards. That is useful if you would like to review the generated job. 

You can later change it back to "Y" if all is well. 
Now, you are ready to explore our newest changes. 

Customizing VSAM allocation attributes using the new v5.5.0 naming standard

In this example and in the ones listed further down, the high-level qualifier for the allocated data sets will use the value of KD2_OMPE_VSAM_DSHLQ for VSAM types or KD2_OMPE_DSHLQ for sequential types. If not customized, KD2_OMPE_VSAM_DSHLQ would default to RTE_VSAM_HILEV.RTE_NAME, and KD2_OMPE_DSHLQ would default to RTE_HILEV.RTE_NAME. 
So, for example, we have this KD5$lpar member with the following configuration: 

This setup would result in the allocation of three Near-Term history VSAM data sets: 
KD2_OMPE_VSAM_DSHLQ.DB.RKD2V001 on VOL1 
KD2_OMPE_VSAM_DSHLQ.DB.RKD2V002 on VOL2 
KD2_OMPE_VSAM_DSHLQ.DB.RKD2V003 on VOL3

Note that the low-level qualifier takes the RKD2V* prefix by default. Because this is different from the RKD2VS* prefix used back in version 5.4.0, it can cause some compatibility issues.  

Customizing VSAM allocation attributes using the v5.4.0 naming standard

We can mitigate the naming convention problem mentioned above by using a new parameter that allows you to fall back to the RKD2VS* prefix: 
   KD2_PFnn_HIS_VSAM_PREFIX

The default value is "V", and you are allowed to change it to "VS". No other prefixes are allowed. So, the same configuration with the backwards-compatible prefix would look like this: 

In this case, the following data sets would be allocated:
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS01 on VOL1
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS02 on VOL2
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS03 on VOL3

Note that when you use the VS option, you cannot specify more than 99 data sets in the log number parameter due to data set qualifier length limitation.

Using the v5.4.0 naming standard but not customizing VSAM attributes

KD2_PFnn_HIS_VSAM_CUSTOMIZE and KD2_PFnn_HIS_VSAM_PREFIX are independent parameters, so the following configuration is also valid:

Because you do not customize the allocation attributes, KD2_PF01_HIS_VSAM_VOLUME1-3 parameters will be ignored, and KD2_PF01_HIS_VSAM_VOLUME is used instead. All VSAM data sets would then be allocated on the same volume:
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS01 on VOL4
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS02 on VOL4
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS03 on VOL4

The concept can be illustrated simply:

Customizing SMS attributes for VSAM data sets

If you use SMS to manage your thread history VSAM data sets and want to use unique management or storage class attributes, you can do that as well, and the principle is the same. Let us have a look at this example configuration:

Data sets in this case would be allocated as follows: 
RKD2VS01 assigned STOR1 storage class and MGMT1 management class
RKD2VS02 assigned STOR2 storage class and MGMT2 management class
RKD2VS03 assigned STOR3 storage class and MGMT3 management class

Enhanced 3270UI Thread History - latest updates

One more important enhancement is regarding allocation of the enhanced 3270UI VSAM data sets. Previously, their attributes for volume, storage, and management classes were taken from parameters KD2_PFnn_HIS_VSAM_VOLUME1, KD2_PFnn_HIS_VSAM_SCLAS1, and KD2_PFnn_HIS_VSAM_MCLAS1; that is, they were reusing the Classic Near-Term History parameters (KD2_PFnn_HIS*). We updated internal logic for e3270UI thread histories to use their own unique parameters following the naming convention of existing e3270UI Thread History parameters (KD2_PFnn_THRDHIS_*):
   KD2_PFnn_THRDHIS_VOLUME
   KD2_PFnn_THRDHIS_MCLAS
   KD2_PFnn_THRDHIS_SCLAS

These new KD2_PFnn_THRDHIS_* parameters will take the defaults from the RTE parameters RTE_SMS_VSAM_VOLUME, RTE_SMS_VSAM_STORCLAS, and RTE_SMS_VSAM_MGMTCLAS – the same defaults as in previously used KD2_PFnn_HIS* parameters. It is likely that you were not using those defaults. Because of this, once you apply the latest maintenance, make sure that the new values match those previously used in VOLUME1, SCLAS1, and MCLAS1 as these values will not be transferred to the new THRDHIS parameters automatically. If the defaults do not work for you, just add these parameters to RTEDEF(KD5$lpar) right away (in Configuration Manager), or update their values in the WCONFIG(rte_name) member (in PARMGEN).

A setup with multiple types of histories enabled 

Our last example will have a combination of available histories: e3270UI Thread Histories, and both types for Classic Near-Term history – VSAM and sequential. Amend your initial history parameters to match these values:

Then you can specify your customizations:

This setup would allocate the data sets on the following volumes:
KD2_OMPE_VSAM_DSHLQ.DB.RKTH0001-7 on VOL7
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS01 on VOL1
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS02 on VOL2
KD2_OMPE_VSAM_DSHLQ.DB.RKD2VS03 on VOL3
KD2_OMPE_DSHLQ.DB.RKD2S001-4 on VOL4

Note that the logic relating to allocation of sequential data sets was not changed. 

We hope that this update on OMEGAMON for Db2 history data set configuration will help you streamline your customization process. 

#IBMZ #AIOpsonZ #OMEGAMON #IBMZOS