MQRC 2053: Queue full

What it means

Every local queue has a maximum depth (MAXDEPTH, or MaxQDepth in the MQI). When the current depth reaches it, the next put fails with MQCC_FAILED and reason 2053. The message isn't stored. Uncommitted puts count toward the depth, so a queue can be full even when a reader sees fewer messages.

A full queue nearly always means the reader stopped or slowed down while writers carried on. The limit is a safety valve. Without it, one stuck consumer could use up the disk or page set and affect every other queue.

The code also appears on channels. When a receiving channel agent can't put an arriving message because the target queue is full, it puts the message on the dead-letter queue with 2053 in the dead-letter header, or puts 2053 in the Feedback field of a report message. If there is no dead-letter queue, or it is full too, the channel retries and can stop. A full transmission queue makes puts to remote queues fail with 2053 at the sending application. The same reason code identifies the Queue Full event.

Common causes

• The consuming application stopped, crashed or is disconnected, so nothing removes messages.
• The consumer is running but slower than the producers, for example during a peak or after a downstream database slowed down.
• Gets are disabled on the queue (GET(DISABLED)), so the queue only grows.
• A transmission queue fills because the channel to the remote queue manager is stopped or retrying.
• MAXDEPTH is set too low for normal peaks.
• A dead-letter queue, statistics queue or accounting queue fills because nobody processes it. IBM documents AMQ7315E and AMQ7316E for the statistics and accounting case.

How to find the problem

1. Compare depth with the limit using DISPLAY QLOCAL(ORDERS.IN) CURDEPTH MAXDEPTH IPPROCS OPPROCS GET. IPPROCS of 0 means no reader has the queue open.
2. Use DISPLAY QSTATUS(ORDERS.IN) TYPE(QUEUE) ALL to see LGETDATE and LGETTIME (when a message was last got) and MSGAGE (age of the oldest message), if queue monitoring is on.
3. For a transmission queue, check the channel with DISPLAY CHSTATUS(QM1.TO.QM2) ALL.
4. On z/OS, issue the same commands with the command prefix. A shared queue that fills its coupling facility structure gives a different code, 2192, so check which one you have.
5. If queue depth events are on, look for Queue Full and Queue Depth High events on SYSTEM.ADMIN.PERFM.EVENT to see when the depth started to rise.

How to fix it

• Restart or fix the consumer first. Once it runs, the queue drains and puts start working again.
• Start more instances of the consumer if it can't keep up, as long as the application can share the queue.
• Raise the limit with ALTER QLOCAL(ORDERS.IN) MAXDEPTH(n) if peaks are normal. Check disk or page set space first, since a deeper queue needs room.
• Make producers handle 2053 by waiting and retrying, not by discarding the message.
• Set QDEPTHHI with queue depth high events, or your monitoring tool's equivalent, so you hear about a filling queue before it is full.

What it looks like

JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2053' ('MQRC_Q_FULL').

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s MQ documentation for your version.