Queue statistics are IBM MQ built-in counters that answer how much traffic used this queue since we last looked—without sniffing payloads or writing custom probes. When STATQ is enabled on ORDERS.IN, DISPLAY QSTATUS or PCF inquire calls return put and get totals, browse activity, and other fields your version documents. Capacity planners graph deltas as messages per second; incident responders compare put rate to get rate when CURDEPTH climbs. Beginners confuse depth with totals: depth 5000 can coexist with millions of lifetime puts if consumers usually keep up. This tutorial explains enabling STATQ, reading statistics attributes, RESET QSTATS discipline, exporting to monitoring stacks, pairing statistics with performance events, z/OS considerations, and operational reports that justify MAXDEPTH changes with evidence.
12345678ALTER QLOCAL('ORDERS.IN') STATQ(ENABLED) DISPLAY QLOCAL('ORDERS.IN') STATQ DISPLAY QSTATUS('ORDERS.IN') * Review put/get and other stat fields for your MQ version RESET QSTATS('ORDERS.IN') * Clears statistics — run only with change approval
STATQ on transmission queues and system queues follows same mechanics but different operational owners. Enable statistics on tier-1 application queues first; expand when exporter capacity allows. DISPLAY QSTATUS may require the queue to be open or may show last collected values per version—read IBM docs before automating.
| Statistic concept | Meaning | Operational use |
|---|---|---|
| Put count | Successful puts since reset | Publisher rate, batch volume proof |
| Get count | Successful gets since reset | Consumer rate, drain validation |
| Browse count | Browse operations | Detect browse-heavy tools harming performance |
| Expired message count | Messages expired per policy | TTL and clock skew issues |
| CURDEPTH (status) | Current backlog | Pair with rates for incident triage |
Sample put count at T0 and T1 five minutes apart. Rate equals (put1 minus put0) divided by 300 seconds. Prometheus rate() on exported counters automates this. If counters reset after RESET QSTATS or queue manager restart, rate() shows a spike or dip—exclude reset windows in dashboards or annotate maintenance. Compare put rate to get rate: sustained put greater than get implies rising CURDEPTH unless messages are non-persistent and discarded by policy.
Reset before controlled load test to measure only test traffic. Reset after application deployment to compare week-over-week on new code. Do not reset during active incident investigation—you lose evidence of burst volume. Document resets in change tickets. Some teams never reset production counters; they rely on Prometheus counters that survive independently of MQ RESET.
Queue statistics summarize queue-level activity. Accounting MQI records (API accounting) capture per-application MQI usage—different tutorial. Use statistics for queue hot spots; use accounting when you need which connection handle or user drove load.
Peak hour put rate 4000 per second, average message size 2 KB, retention minutes on queue near zero under normal get rate. MAXDEPTH 100000 covers roughly twenty-five seconds at peak if consumers stop—too tight. Statistics from last Black Friday prove peak sustained 3500 per second for forty minutes—justify MAXDEPTH and consumer scale with numbers, not guesses.
Statistics are the car odometer (total miles driven). CURDEPTH is the fuel gauge (how full right now). Both matter for different questions.
Statistics count how many marbles were put in the box and taken out since breakfast. Depth is how many marbles sit in the box right this second.
Given put count 1,200,000 at 09:00 and 1,350,000 at 09:05, calculate average put rate per second.
List five queues you would enable STATQ on first in production and why.
When would you run RESET QSTATS during an incident—and when would you refuse?
1. STATQ(ENABLED) on a queue:
2. Put count in statistics measures:
3. RESET QSTATS is used to:
4. Put rate from statistics uses: