Queue full is one of the most common production alarms in IBM MQ: producers keep putting messages, consumers or channels cannot keep up, and CURDEPTH climbs until it hits MAXDEPTH. The next MQPUT fails with reason 2053—MQRC_Q_FULL—and upstream systems may cascade failures into databases, APIs, and batch schedules. Beginners increase MAXDEPTH and close the ticket; experienced operators ask why depth rose and whether disk, channels, or application threads are the bottleneck. This tutorial explains how queue full works, how 2053 appears to applications and in AMQERR, differences between application queues and transmission queues, PUT inhibited and disk full edge cases, monitoring and alerting patterns, safe remediation steps, and prevention through sizing and architecture.
For a local queue, the queue manager tracks CURDEPTH (current message count) against MAXDEPTH (maximum allowed messages). Each successful non-unit-of-work put increments depth; each successful get decrements it. When CURDEPTH would exceed MAXDEPTH after a put, the put fails with completion code 2 and reason 2053. This is count-based fullness, not byte-based—a queue can be full with small messages while disk still has space, or have low count but huge messages stressing storage via MAXMSGL limits. MAXMSGL rejects oversized single messages with different reason codes; do not confuse the two during triage.
| Symptom | Likely cause | Check first |
|---|---|---|
| 2053 on application queue | Slow or stopped consumer | DISPLAY QSTATUS CURDEPTH IPPROCS OPPROCS |
| 2053 on XMITQ | Channel INACTIVE/RETRY | DISPLAY CHSTATUS, XMITQ depth |
| Put fails, depth below MAXDEPTH | Disk full or QM limit | Filesystem, DISPLAY QMSTATUS |
| Put fails, PUT inhibited | Administrative inhibit | DISPLAY QLOCAL PUT |
Java may throw MQException with reason 2053; C and COBOL return the reason in the completion code structure; .NET wrappers surface MQRC_Q_FULL. Well-behaved producers implement bounded retry with backoff and alert when depth stays high. Poor producers spin in tight loops hammering the queue manager and worsen CPU load. Teach development teams to log queue name, queue manager, and depth when 2053 occurs. On the server, AMQERR may log queue full context depending on release and activity—pair with DISPLAY QSTATUS on the queue in question.
123456DISPLAY QSTATUS('PAYMENT.IN') CURDEPTH IPPROCS OPPROCS DISPLAY QLOCAL('PAYMENT.IN') CURDEPTH MAXDEPTH PUT GET * If XMITQ is full: DISPLAY QSTATUS('SYSTEM.DEAD.LETTER.QUEUE') DISPLAY QSTATUS('QM_PARIS.XMIT') CURDEPTH DISPLAY CHSTATUS('PARIS.TO.LONDON')
When PAYMENT.IN fills, ask whether any application has the queue open for get (OPPROCS). Zero OPPROCS with rising CURDEPTH means no consumer is running—check CICS transactions, batch jobs, or microservice pods. Multiple consumers with low throughput may indicate poison messages, database locks, or downstream API timeouts causing slow gets. Triggered queues may not fire if trigger monitor is down—depth grows while trigger configuration looks correct. Fix the consumer path first; only then tune MAXDEPTH if sustained peaks justify it.
Transmission queues hold messages waiting for a channel to deliver them to a remote queue manager. When the channel is INACTIVE, in RETRY, or RUNNING but slow, XMITQ depth climbs. Sender channels drain XMITQ; if the partner receiver is down or network fails, the sending side stores messages until MAXDEPTH. This is store-and-forward protecting messages, but unbounded growth without sizing is an outage waiting to happen. Restore the channel, fix TLS or CHLAUTH if bind fails, and size XMITQ for expected outage duration multiplied by peak put rate. A full XMITQ can block applications putting to remote queues even when local application queues are empty.
Even with MAXDEPTH headroom, the filesystem hosting queue files may be full. Symptoms can include puts failing without clean 2053 or with messages about storage in AMQERR. Monitor disk on QMDATA and log paths together with queue depth dashboards. Log utilization spikes sometimes correlate with heavy persistent put rates filling both logs and queues. z/OS administrators watch page sets and storage groups in addition to CURDEPTH.
Alert on CURDEPTH as a percentage of MAXDEPTH (for example eighty percent warning, ninety-five critical). For queues with MAXDEPTH(0) or very large limits, use absolute depth thresholds and disk alerts. Prometheus MQ exporters expose depth metrics; mainframe teams may use Instana or queue statistics. Correlate depth alerts with channel status panels—XMITQ alerts without channel checks waste time. Include put rate and get rate when available to distinguish burst from sustained backlog.
Size MAXDEPTH using peak messages per hour times maximum acceptable outage hours for transmission paths. Application queues need enough depth for batch spikes plus consumer maintenance windows. Document who may ALTER MAXDEPTH in production. Use alias queues and routing so non-critical traffic does not share one shallow queue with payments. Consider multiple consumers or partitioned workloads before infinite depth increases.
A queue is a mailbox with a fixed number of slots (MAXDEPTH). Mail keeps arriving (puts) but nobody empties it (gets). When every slot is full, the post office refuses more letters until someone takes mail out—or you add slots temporarily while you hire a mail clerk.
The toy box can only hold ten toys. You tried to put an eleventh toy in and it would not fit. You need to take some toys out or get a bigger box—but if nobody ever takes toys out, a bigger box only helps for a little while.
On lab QM, fill a test queue to MAXDEPTH and observe 2053 from a test put program. Record CURDEPTH.
Calculate XMITQ MAXDEPTH for one hour outage at 500 messages per second. Show your math.
Write an alert rule: depth percent, duration, and who gets paged for payment vs audit queues.
1. Queue full reason code is typically:
2. CURDEPTH equals MAXDEPTH means:
3. XMITQ full often indicates:
4. First response to chronic queue full: