AIOps: Monitoring and Observability - Group home

OMEGAMON® Near Term History PDS V2 News

By JOE WINTERTON posted Thu July 01, 2021 02:47 PM

On our journey to move OMEGAMON® users to the new Persistent Data Store  (PDS) V2 implementation for ITM Near Term history in the Enhanced 3270UI, the following three new user stories have been implemented via OA60244/UJ05411 (HKCI310) and OA61008/UJ05412 (HKOB550):


1.  As an OMEGAMON PDS V2 user, I want to be able to configure PDS V2 using IBM® Z Monitoring Configuration Manager (Configuration Manager) or PARMGEN, without having to perform manual steps and following long ++HOLD actions and without having to do housekeeping on PDS V1 artifacts that are irrelevant with use of PDS V2.


2.  As an OMEGAMON PDS V2 user, I want to be able to selectively roll out PDS V2 for my various products using Configuration Manager or PARMGEN to support a phased rollout.


3.  As an OMEGAMON PDS V2 user, I want to be able to customize allocations for my various PDS V2 data sets on a per agent/product basis to adhere to naming conventions and company-wide standards.


The following picture gives you an overview of the new parameters introduced to implement the above user stories (see user story #1).



In general, there are two sets of parameters introduced: Run Time Environment (RTE) and Agent-specific parameters, thus following the PDS V1 respective approach taken.

RTE parameters apply to all agents entitled to use PDS V2 and mainly define storage-related aspect for the PDS V2 implementation as well as a High Level Qualifier for PDS V2 data sets.

Agent-specific parameters allow you to configure the data store allocation size and to selectively “opt in” or “opt out” from PDS V2 .

After you customize/specify these new parameters, make sure you run your Configuration Manager “GENERATE” action or the PARMGEN $PARSE jobs to generate the new members in rHilev.RKANPARU as shown in the above picture.

Further note that in order to help with PDS V1 “housekeeping” activities, a utility has been provided in TKANSAM(KFJMAINT) with ACTION DELPDSV1 to remove the PDS V1 data sets for all agents in an RTE. If you run this utility first with CONFIRM N, it will only print the list of data sets to be deleted in the KCIPRINT DD. Select CONFIRM Y to delete the data sets for good (see user story #1).


Finally, note that the latest OMNIBASE 750 code level provided via OA61008/UJ05412 implements a better use of the DASD space in the PDS V2 files and defaults to round-robin data set use (“space-based allocation”, same as PDS V1 has used) to eliminate data set full issues.

We recommend applying the code so users now get to this PDS V2 level.


For more details:

Product documentation:

PDS V2 installation: