Today some queue level information can be extracted in two ways; either from the SMF Task accounting data (class 3), or by issuing periodic RESET QSTATS and DISPLAY QSTATUS commands and capturing the responses. Knowing the number and type of requests along with the volume of data being processed in individual queues is critical to track usage, do trend analysis, resizing storage containers, moving from private to shared queues, problem determination, etc.
The MQ Task accounting data has the advantage of being the most complete and informative. It has the disadvantage to being costly to gather, process, and store. And even the most sophisticated queries often cannot get the individual queue use to align with the normal MQ statistics interval.
Using the commands has the advantage of being less expensive. It is the technique used by most, if not all, MQ monitoring tools. However, it does not include information that may be required for both volume analysis and problem determination. The RESET QSTATS command can interfere with any other tool issuing that command. Also there is no reliable way to coordinate the command results with the SMF intervals used for other types of performance and trend analysis.
What is required is a way to gather actual queue statistics reporting for individual queues that is produced at the SMF intervals, another SMF115 subtype. It would be helpful to have this data as part of the SMF data and optionally to be published to any number of subscribers. The data would include information that is like some of the data gathered for the WQ records and some from the queue status.
This data will provide more immediate feedback on the application activity and can drive automated action to address changes in message volume. .
The following fields are necessary:
Open Name
Base Name
CF Structure
Bufferpool ID
Pageset ID
High Number of input processes with the queue open
Lowest number of input processes with the queue open
High Number of output processes with the queue open
Lowest number of output processes with the queue open
Current Number of input processes with the queue open
Current number of input processes with the queue open
Open Count
Close Count
Get Count
Maximum Depth during Interval
Valid Get Count
GET Total Bytes
GET Min message size
GET Max message size
Minimum Time on Queue
Maximum Time on queue (oldest message retrieved)
Skipped Count
Expired Count
Get Persistent Message Count
Put Count
Put1 Count
Valid Put Count
PUT total Bytes
PUT Min message size
PUT Max message size
Generated Message Count
PUT Persistent Message Count
PUT1 Persistent Message Count
PUT to waiting getter count
PUT1 to waiting getter count
MQINQ Count
MQSET Count
Other fields that might be useful for tuning and evaluation:
Number of Gets with a Wait that expired during the interval
This could be used to set the number of application instances required
Number of Gets that retuned a ‘2033' – with no wait
Current number of Gets with a wait active
Number of puts that failed
Fully delivered in 9.3.3
We are looking at enhancements in this area for a future version of MQ
Expired message count should include messages that are removed as part of the expiry scavenger, too. Thanks
Please note that topic statistics should also be included in this request. Sixteen years ago when this was originally created topics were not part of MQ for z/OS.