MQRC 2033: No matching message available

What it means

MQGET returns 2033 when nothing on the queue matches what it asked for. Without MQGMO_WAIT it returns at once. With MQGMO_WAIT it waits for the time in the WaitInterval field and returns 2033 if no matching message arrives. A browse also returns 2033 when it reaches the end of the queue.

This is the normal way a reader learns the queue is empty, and most programs handle it as end of input. It becomes a problem when you know a message was sent and the reader still gets 2033. Then the message is there but not available to this get, or it never arrived on this queue.

A message isn't available if it was put under syncpoint and not yet committed, if it has expired, or if it doesn't match the MsgId, CorrelId or other match options in the get. Messages in a group or segmented messages can also stay out of reach when options such as MQGMO_ALL_MSGS_AVAILABLE ask for the whole set. In JMS, a receive with a timeout returns null instead of raising 2033.

Common causes

• The queue is empty and the program didn't wait, or waited less time than the sender needed.
• The sender put the message under syncpoint and hasn't committed yet, or backed it out.
• The program reuses the MQMD after a get without resetting MsgId and CorrelId to MQMI_NONE and MQCI_NONE. The next get then looks only for the message it already took.
• The message expired. Messages past their Expiry time are discarded instead of returned.
• The message went somewhere else, such as another instance of a cluster queue, a remote queue definition, the transmission queue or the dead-letter queue.
• The get asks for a complete group or a complete segmented message, and not all parts have arrived.

How to find the problem

1. Check the queue directly with DISPLAY QLOCAL(ORDERS.IN) CURDEPTH and DISPLAY QSTATUS(ORDERS.IN) TYPE(QUEUE) UNCOM. A depth above zero with uncommitted changes points to a sender that hasn't committed.
2. Browse the queue with amqsbcg or dmpmqmsg on distributed MQ, or a browse tool on z/OS, and compare MsgId, CorrelId and Expiry with what the get asks for.
3. Log the MQMD and MQGMO the program passes. Look at MatchOptions, MsgId, CorrelId, WaitInterval and the group options.
4. If the queue is empty, follow the message path. Check the sender's target queue, the transmission queue depth, channel status with DISPLAY CHSTATUS(*) and the dead-letter queue.
5. In a cluster, check depth on every instance of the queue. Workload balancing can send the message to a different queue manager.

How to fix it

• If 2033 means the queue is empty, treat it as normal and end the loop or wait again.
• Reset MsgId to MQMI_NONE and CorrelId to MQCI_NONE before each get that shouldn't match on them, or use MatchOptions of MQMO_NONE.
• Make sure the sender commits. Check that MQCMIT, EXEC CICS SYNCPOINT or the JMS commit really runs.
• Set a WaitInterval that fits how long the reply can take, for request and reply designs in particular.
• If messages expire before they are read, raise the Expiry the sender sets or speed up the reader.

What it looks like

MQJE001: Completion Code '2', Reason '2033'.

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.