The following article describes the resource considerations when configuring OMEGAMON PDSv2 history collection.
Both CPU and storage usage can be kept to a minimum by configuring history collection for only those OMEGAMON tables and metrics that are required with the appropriate collection time intervals. These settings may vary from one environment to another.
While the space taken by PDSv2 data sets varies on different systems, there are several ways to optimize their storage usage.
The first most common used strategy is the space-based data set management node. In this case the amount of historical data in each data set depends on the size of the data set. The number and size of the data sets allocated are defined using parameters Kpp_PDS2_FILE_COUNT and Kpp_PDS2_STORE_SIZE. These data sets are online at all times. All the allocated data sets except for one are used for writing data, while one data set remains empty for future switches. The switch to the next data set occurs when the current data set runs out of space; no extents are taken when the current data set is full. Many customers want enough PDS V2 History to allow a look back for at least 3 days so on a Monday they could investigate an issue over the weekend. Others want a full weeks work of History data for an OMEGAMON agent.
If you’d like to determine approximate space needed for the particular system and agent, you may use the default allocation sizes during the initial configuration and the observe how much space is left in the active data set the next day. Based on the observation results you may reconfigure PDSv2 and adjust the data set size (Kpp_PDS2_STORE_SIZE) accordingly.
Another option is to use the time-based switch policy which allows having 24 hours of history records per data set. The number and size of the data sets allocated are defined using parameters Kpp_PDS2_FILE_COUNT, Kpp_PDS2_STORE_SIZE and Kpp_PDS2_SEC_SIZE. These data sets are online at all times. All the allocated data sets except for one are used for writing data, while one data set remains empty for future switches. The switch to the next data set occurs around local midnight.
When the current data set fills up and cannot be extended, recording rolls over to the next data set and less than 24 hours of data may be present in the data set. It is important that each PDS V2 data set be large enough to contain historical data for a full 24-hour period.
To use this mode, allocate the data set using an SMS data class that has the Extent Constraint Removal (ECR) parameter set to a value of YES. The data class can be assigned using the SMS data class ACS routine.
Useful links:
Data set management modes: https://www.ibm.com/docs/en/om-shared?topic=v2-data-set-management-modes
More details on configuring data set size, count, etc.: https://www.ibm.com/docs/en/om-shared?topic=cpv-how-change-pds-v2-file-count-file-size
#IBMZ #OMEGAMON #ZAIOPS #PDSV2 #IBMz/OS