About the PDS (the Persistent Data Store)

Anyone who has done an install of any of the OMEGAMONs on z/OS has gone through the exercise in the ICAT installer of configuring the Persistent Data Store (PDS). Odds are if you've done it, you have executed the configuration steps multiple times (once for each TEMS and once for each agent TEMA task on each LPAR). This adds up to doing what seems to be the same task many times over and over. The question may be, is this really necessary?

If you plan on using the history functions of the Tivoli Enterprise Portal, displaying the data in the TEP, and optionally sending the history data to the Tivoli Data Warehouse (TDW), you will need this infrastructure in place to some extent. If you are not planning on using these functions, then you can get by without doing this work. One exception to this would be OMEGAMON XE For Storage, which will require the PDS for all its various features.

My recommendation is to go ahead and set up the PDS, at minimum, at the level of the TEMS. This gives you the option of collecting at least some history data in the TEP. Keep in mind though, that this may cause some confusion with users if they are trying to collect history at the level of the TEMA, but the PDS in the TEMA is not set up.

If you can, configure the PDS for each component, TEMS and TEMAs. Often I will scale down the default size allocations of the PDSs for the various components, just to save space (this stuff can add up across many systems and agents). But, I will go ahead and create the files per the steps in ICAT. This means that a user will be able to get the history to function from the TEP without having to worry about the underlying infrastructure being in place. It may not be optimal, but it will at least function.

With that being said, you may need re-create the files with more space if usage goes up. So if users are taking advantage of the history facility, it is a good idea to monitor usage, and make adjustments if usage increases.