Create historical data collections


To ensure that ODP forwards attributes to Instana as soon as you start collecting them, update the ODP collection configuration member KAYOPEN before creating the corresponding historical data collections.


With higher granularity (a smaller interval means more data collected) there are 2 obvious considerations:

  1. CPU overhead on data collection and retrieval;
  2. DASD space to hold historical tables.

Should you grow in CPU usage or Persistent Data Store, consider raising the interval and/or skipping warehousing for certain tables on PDS and just go with open data.

Create the following historical data collections for the MQ agent. This can be done via the E3270UI or the Tivoli Enterprise Portal within the MQ workspace.

table_name field valueAttribute groupCollection interval (minutes)
qmcurstatCurrent Queue Manager Status1
qmq_lhQueue Long-Term History5
qmq_qu_stQueue Status1
qmtpcstTopic Status1


For all on-demand attribute groups with “Queue” in the name (except Current Queue Manager Status), if there is too much data, you should specify a longer interval. This is very customer-dependent – some have many (thousands of) queues per queue manager, some do not. Topics and channels could have the same issue, but perhaps not as likely as queues.

The basic rule is that a sampled table should not have an interval any more often than the sample interval (SAMPINT parameter) to the agent, which is 5 minutes by default; other tables can be more frequent if desired. This chapter should be consulted for considerations: IBM OMEGAMON for Messaging on z/OSopen in new window

Last Updated:
Contributors: Jim Porell