ITM Integration Series: Setting up short term historical collection for Omegamon z/OS DB2 agents
Oneil 20000003NT Visits (6108)
In this blog I'll cover a recent issue I found when assisting a customer to set up short historical collection for their Omegamon XE for DB2 Performance z/OS agents.We found that even though historical collection had been enabled in the TEMS it was not possible to select historical data for the agent to be displayed in the TEP workspaces, nor was it possible to see realtime data. After some further digging it was found that unique to the z/OS KD5 agent are some historical collection parameters that also need to be set to match those at the TEMS for historical collection to work and for the TEP to be able to correctly dispaly realtime data. This blog covers the investigative steps and settings that were changed to correctly enable short term historical collection for this agent
Initially the problem was reported as a TEPS issue; the customer was not able to see real time data from the agent.
After confirming the customer had not customized the default workspace views I checked if the short term historical collection had been correctly enabled for the correct attributes.
Collection Location: TEMS
Collection Interval: 5 mins
Warehouse Interval 5 mins
I checked the default location for the short term historical collection binary at the TEMS ($CA
This was backed up by the following output in the TEPS logs once additional tracing (see bottom for settings) had been enabled to view the query SQL and resulting rows found...
Checking this theory out it was found that the binary did indeed exist at the TEMA agent. After discussion on this issue further with the z/OS DB2 agent team the following information was discovered...
- The z/OS DB2 agent is installed and configured using PARMGEN
This was in effect setting up historical collection at the TEMA agent and contradicting the historical collection settings that were enabled at the TEMS (where the short term history location was configured to be on the TEMS). It was this configuration that was causing the unexpected behaviour at the TEPS, as the query was expecting to find the short term history at the TEMS when it instead it existed at the TEMA.
To resolve the problem, the customer decided to modify the z/OS DB2 TEMA collection settings to match the historical collection settings at the TEMS
After restarting the agent, the customer was able to see collection take place at the TEMS and real time data display correctly in the TEP. At this point it was noted that the 'Realtime + X hours' view was still inactive.This was confirmed to be working as designed based on the type of display chart the workspace was using...
The following information from p.214 of the 6.3 TEP User guide states:
General Information for enabling historical collection at the TEMS versus enabling at the TEMA...
The performance implications for the data gathering step in large scale environments with several hundred agents connected to one TEMS are:
- Large chunk of data warehousing from one box vs. much smaller chunk of data warehousing from multiple boxes.
- All agents write to one file for each attribute groups. Slow workspace response time for shot-term historical data.
- Demands large disk storage, CPU and memory usage of the TEMS.
- Drastically lowers the number of agents that can be managed by the TEMS
- Loss of access to the short term historical data during a failover to a secondary TEMS.
Subscribe and follow us for all the latest information directly on your social feeds: