OMEGAMON XE for CICS Persistent Data Store (PDS) Sizing Considerations
Bob_Horne 1100008GYP Visits (9038)
On z/OS data collected during the OMEGAMON history collection process is stored in the OMEGAMON Persistent Data Store (PDS). In this blog entry we will discuss PDS sizing considerations for the OMEGAMON XE for CICS and the OMEGAMON XE for CICS TG product components.
The PDS is a set of pre-allocated flat files that are re-used on an oldest data basis. When the active PDS data set becomes full, data collection will switch to the next empty PDS file. When there are no more empty PDS data sets, the PDS data set containing the oldest data will be emptied and initialized for reuse.
In this blog we will use the term PDS when we are referring to the collective DASD space or the collective processing of the individual files. We will use the term PDS data set(s) when we are referring to an individual file or the set of files which comprise the PDS.
There are several PARMGEN parameters which are significant to the configuration of the PDS for the OMEGAMON XE for CICS and OMEGAMON XE for CICS TG product components. The first parameter is the PARMGEN RTE_PDS_FILE_COUNT parameter which specifies the number of PDS files allocated per product in a given run-time environment (RTE). The default value for the RTE_PDS_FILE_COUNT parameter is six (6) files.
The other parameters are the PARMGEN KC5_PD_CYL and KGW_PD_CYL parameters which specify the total size in cylinders in the PDS for the OMEGAMON XE for CICS product component and the total size in cylinders for the OMEGAMON XE for CICS TG product component. The default value for the KC5_PD_CYL parameter is 600 cylinders and the default value for KGW_PD_CYL is 76 cylinders. The specified values represent the total DASD space to be allocated to the PDS for that component. The specified value will be divided among the PDS data sets to be defined.
The PDS maintenance process attempts to always have an empty PDS data set available to expedite the file switching process. For this reason fewer than the total number of PDS data sets will actually contain data at any given time. On average only the total number of PDS data sets less one and one-half data sets will contain data. This should be taken into consideration when specifying the KC5_PD_CYL and KGW_PD_CYL parameter values.
The default values for both product components are considered to be sufficient to accommodate three days of Near Term History (NTH) data when history is being collected at 5 minute intervals. For the OMEGAMON XE for CICS product the representative monitored environment would be comprised of 10 to 15 CICS regions. For the OMEGAMON XE for CICS TG product component the representative monitored environment would be comprised of any combination of 3 to 5 CICS Transaction Gateway (CTG) daemons and 3 to 5 WebSphere Application Server (WAS) environments.
It should be noted that these are at best only rough approximations. There are so many factors which would influence the amount of history data collected in a given environment that it is nearly impossible to provide a more accurate approximation. You will need to monitor PDS file usage in your environment and adjust the KC5_PD_CYL and KGW_PD_CYL values accordingly.
There are a number of automated PDS processes associated with the collection of history data. When the currently active PDS file becomes full there is an automatic switch to the next empty PDS file. When there are no more empty PDS files, a PDS maintenance process will be automatically initiated to initialize and reuse the PDS file which contains the oldest history data.
History data is only removed from the PDS data sets by the PDS maintenance process when there is a need to initialize and reuse a PDS file. History data is not removed from the PDS by the Warehouse Proxy agent during the export process to the Tivoli Data Warehouse (TDW).
Messages related to PDS processing are written to the RKPDLOG output destination in the job output of the agent address space. Messages related to the initial status of the PDS files and messages related to PDS file switches can be found in the RKPDLOG output.
A system administrator should review the output messages in the RKPDLOG to determine how often PDS file switches are occurring. The number of PDS file switches will be an indication of whether the size of the PDS needs to be increased. For example in an environment where there are the 6 PDS files defined and there is a goal to house 3 days of history data for NTH viewing in the enhanced 3270UI, there should be fewer than 2 PDS file switches per day.
Further information about maintaining and monitoring the OMEGAMON Persistent Data Store can be found in the IBM Knowledge Center at the following link:
The capabilities described above are available with the OMEGAMON Performance Management Suite.