Queue Statistics versus Queue Status Message Statistics versus Queue Status

Queue Statistics verses Queue Status

There is not an easy yes or no response to Queue Statistics verses Queue Status. Some things to consider:

1) Sometimes, if there are a significant number of queues and situations, it is often better to just use queue statistics, since it is only collected once every 5 minutes even if there are 50 situations.

2) The queue status table is on demand. If it repeatedly requests data for all queues, both the KMQ agent and queue manager CPU may go up.

3) It will really depend on how many situations, the type of situations, situation intervals etc. The processing of queue status, will only ask for a specific queue if ONLY 1 queue asked for in the situation. If there are some situations with more than one queue name, then they will ask for all queues and it will be filtered by IBM Tivoli Monitoring (ITM). If some situations have been "grouped" together for CMS_DUPER, it will request all.

4) For Queue statistics requests, even with 140 Alias queues, agent level that has performance fix IV19729 should be used. (V701 FP2 IF01, but really since this is EOS, should be V710 or V730).

5) Using event situations where possible would always be better since alerts will be generated when MQ series events occur - no extra cost of collecting data.

Message Statistics verses Queue Status

1) For the MsgAge situations, change situations to use Queue Status instead of Message Statistics. "Oldest Msg Age" is the attribute.

2) Message statistics attribute group contains more information than Queue Status, such as % delayed and breakdown by priority. But if only concerned about the Oldest_Message_Seconds, then use "Queue Status" attribute group instead, Oldest Msg Age attribute.