Queue Depths

Queue depth is the visible pulse of IBM MQ health: how many messages are waiting right now on a local queue, transmission queue, or application queue. Operators live in DISPLAY QLOCAL CURDEPTH during incidents. Architects set MAXDEPTH to cap risk. Developers see depth grow when their consumers cannot keep pace. Depth is not throughput—it is inventory. A queue can show one hundred thousand messages while put rate is zero because producers stopped hours ago; consumers are still draining. Another queue can sit at depth five yet fail every second because MAXDEPTH is five and producers never rest. This tutorial teaches CURDEPTH and related displays, depth versus rate analysis, alerting thresholds, transmission and dead-letter queues, disk implications of deep persistent queues, tuning responses that help versus hurt, and z/OS shared queue nuances for beginners who already read MAXDEPTH but need operational depth management.

CURDEPTH and Related Fields

DISPLAY QLOCAL('ORDERS.IN') CURDEPTH MAXDEPTH IPPROCS OPPROCS MONQ gives a snapshot. IPPROCS greater than zero with rising depth means live producers outpacing consumers. Zero OPPROCS with rising depth means no consumer connected—a deployment bug or crashed listener on the app side. Depth zero with high IPPROCS can mean fire-and-forget non-persistent or immediate gets—context matters.

Depth and Latency

New messages behind a deep queue wait for all ahead of them unless priority features apply. Average wait approximates depth divided by get rate at steady state. Reducing depth through faster consumers lowers latency more than micro-optimizing TLS on an empty queue. Express traffic should use separate queues kept shallow, not one giant queue for batch and real-time together.

Transmission Queue Depth

Messages on XMITQ are logically en route to a remote queue manager. Depth grows when the sender channel is STOPPED, RETRY, or slow. Operations correlate DISPLAY QLOCAL('QM2.XMIT') CURDEPTH with DISPLAY CHSTATUS('TO.QM2'). Store-and-forward protects messages but disk must hold the backlog. Size MAXDEPTH and disk for credible outage duration times peak put rate. Alert XMITQ depth separately from application queues—partners call when their hub is fine but your channel died.

Dead-Letter and Backout Queues

Depth on dead-letter queues indicates poison messages, format errors, or routing failures. Slow growth may be acceptable if operations reviews daily. Sudden spikes need immediate triage—often a bad release. Backout queues from BOTHRESH show consumer rejection patterns. Do not clear DLQ depth without understanding payloads—compliance may require retention.

Disk and Memory Impact

Persistent messages in deep queues consume disk on queue files and generate log records. Million-message backlog after an outage can fill filesystems even below MAXDEPTH if MAXDEPTH was set huge. Plan drain time: if get rate is five hundred per second and depth is two million, drain takes over an hour—business must accept delay or add consumer instances.

Alerting Thresholds

1. Warning at fifty percent of MAXDEPTH for payment queues.
2. Critical at eighty percent with page on-call.
3. Rate of change: depth plus one thousand per minute for five minutes regardless of percent.
4. XMITQ depth greater than zero for four hours when channel should be RUNNING.

Static thresholds fail on queues with seasonal scale—use dynamic baselines where monitoring tools support anomaly detection.

Tuning Responses

• Scale consumers or add parallel get threads where ordering rules allow.
• Throttle producers at source system during DR catch-up.
• Fix channel or network if XMITQ depth is the symptom.
• Increase MAXDEPTH only when disk and drain plan support it—not as first fix.
• Enable MONQ and queue depth events for automation.

Cluster and QSG Depth

Cluster queues may show depth on the queue manager instance holding messages. QSG shared queues expose depth visible to all members—competing consumers across LPARs can drain faster than single-instance queues. Interpret depth in cluster context using DISPLAY QCSTATUS where applicable.

Tutorial: Depth Drill MQSC

1
2
3
4
5
6
7
8
9
* Every 5 min during incident
DISPLAY QLOCAL('PAYMENT.IN') CURDEPTH MAXDEPTH IPPROCS OPPROCS
DISPLAY QLOCAL('BANK.XMIT') CURDEPTH
DISPLAY CHSTATUS('TO.BANK') STATUS MSGS
 
* Calculate drain ETA:
* messages_to_drain = CURDEPTH
* if OPPROCS=0 -> fix consumers first
* else ETA_sec = CURDEPTH / measured_get_rate

Explainer: Line at the Ride

Queue depth is how many people stand in line. MAXDEPTH is fire code maximum in the building. Adding capacity to the building does not make the ride faster—you need more ride operators or fewer arrivals.

Explain Like I'm Five

Queue depth is how many marbles are in the jar. If marbles keep coming in faster than you take them out, the jar fills up. When the jar is full, new marbles bounce off—that is MQRC_Q_FULL.

Practice Exercises

Exercise 1

CURDEPTH 450,000, get rate 1,500/s. Estimate drain time in minutes.

Exercise 2

Write warning and critical thresholds for MAXDEPTH 100,000.

Exercise 3

XMITQ depth rising, channel RETRY—list four investigation steps.

Frequently Asked Questions

Test Your Knowledge