OMEGAMON Performance Management Suite: Best Practices in Monitoring the Persistent Data Store (PDS)
Bob_Horne 1100008GYP Visits (9130)
On z/OS data collected during the OMEGAMON history collection process is stored in the Persistent Data Store (PDS). In this blog entry we will provide some insight into how to effectively monitor the PDS maintenance process.
The PDS is a set of pre-allocated flat files that are continually reinitialized and reused. The PDS maintenance process is an automated process which should not require intervention by the system administrator. However, an understanding of the PDS maintenance process will be helpful to system administrators who want to maximize the amount of Near Term History data that is available for viewing in the enhanced 3270UI.
Similar to other OMEGAMON features and functions, the PDS related configuration parameters are specified during the PARMGEN configuration process. The number of PDS files allocated per product in a given run-time environment (RTE) is specified by the PARMGEN RTE_PDS_FILE_COUNT parameter .
The current default value for the RTE_PDS_FILE_COUNT parameter is six (6) files. Each OMEGAMON product in the RTE will have its own set of PDS data sets unless history collection at the TEMS has been specified. It should be noted that history collection at the TEMS is not recommended by IBM.
History data is written to the currently active PDS file. This PDS file will be the only PDS file allocated in “Write” mode. Other PDS files will be allocated in “Read” mode to allow the viewing of previously collected history data.
History collection will automatically switch to the next empty PDS file when the active PDS file becomes full. The PDS maintenance process attempts to maintain at least one empty file to expedite PDS file switching. When there are no more empty PDS files, the automatic PDS maintenance process will initialize and reuse the PDS file with the oldest data. As a result, on average only 4.5 PDS files of the default number of six files will actually contain history data.
PDS related output messages are logged to the RKPDLOG output destination in the address space of the OMEGAMON agent. Below is an excerpt from the RKPDLOG output showing the PDS related activity when a PDS history file becomes full:
The messages shown above were extracted from the RKPDLOG of an OMEGAMON XE for CICS agent address space. However, there will be similar messages written to the RKPDLOG in other OMEGAMON agent address spaces.
The first KPDDSTR message indicates the RKC5HIS2 file has become full. The next set of KPDIFIL messages show the PDS switching to the next PDS file (the RKC5HIS5 file) followed by messages which show the initiation of the automatic maintenance process to initialize and reuse the oldest PDS file (in this case the RKC5HIS6 file). Finally, we see the KPDINDS messages showing initialization has been started and completed for the RKC5HIS6 PDS file.
You will note the PDS file with the RKC5HIS3 low level qualifier has a status of "Partially Full". This indicates the agent address space likely was not allowed to quiesce previously when the RKC5HIS3 file was the active file. The PDS maintenance process will detect this situation upon the next start-up and will initiate a “RECOVER” operation for the file. The RECOVER operation will attempt to restore the contents of the file and close the file properly. After a successful recovery operation the file will be brought back on-line and it will be designated with the “Partial” full status.
The history data contained in the recovered file will be made available again for viewing as NTH data in the enhanced 3270UI. However, there may only be a limited amount of history data available in the file. Accordingly, PDS files which are only partially full will reduce the overall amount of NTH data available for viewing in the enhanced 3270UI. For this reason it is a good practice to shut down the agent address space normally to insure that the active PDS file is closed correctly.
After the OMEGAMON agent has been up and running for a while it will be possible for a system administrator to review the RKPDLOG to see how often PDS file switching is occurring. Browsing the RKPDLOG output for KPDDSTR messages will provide an indication about how often PDS file switches are occurring. If you have six PDS files allocated and you find that six PDS file switches occurred during a 24 hour period, then it is clear that your PDS contains less than a full day of viewable Near Term History data.
Further information about 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.