MQ

 View Only

 Dead Letter Queue Usage

sarvan k's profile image
sarvan k posted Fri March 20, 2026 12:09 AM

Hello IBM community,

I would like to know the usage of DEAD LETTER QUEUE in a normal Queue manager. 

I am using trail version of MQ 9.4 on Windows OS (Laptop) local laptop. I created a normal Queue manager(QM1) and normal local queue (TEST) with Maximum curdepth of 10.

I tried to put on that normal local queue (TEST) messages using "AMQSPUT TEST QM1" on that same command prompt (as Admin) 10 messages they landed on that local queue. But when tried to put 11th messages it is discarded not went into "SYSTEM.DEAD.LETTER.QUEUE". Is this expected behaviour. Will it same occur when someone using binding mode to connect the local queues or queue manager?

In second scenario, I created QM2 .  I tried to establish point to point DQM setup between QM1 and QM2 . Where remote queue (SENDQ), xmit queue, and send channel present on QM1 and RECEVQ (destination queue), listener port, Receiver channel created on QM2. RECEVQ Maxcurdepth is set around 10 . when tried to put messages on SENDQ of QM1 then they are landing on RECEVQ of QM2. Which is expected.

But when it reached more than Maxcurdepth and 11th message is tried to put using same AMQSPUT SENDQ QM1 then that 11th message is landing in "SYSTEM.DEAD.LETTER.QUEUE" I tried to browse that message able to see the reason code also. So is this DEAD LETTER QUEUE usage is restricted to DQM setup kind only? Only MCA channels are allowed to utilise or send messages to SYSTEM.DEAD.LETTER,QUEUE or User define DEAD.LETTER.QUEUE ?

Please comment or throw some light on this observation.

Thanks,

Sarvan Kancharla 

Morag Hughson's profile image
Morag Hughson IBM Champion posted Fri March 20, 2026 12:35 PM

The dead letter queue is used when there is no application to give a return code to.

In your first example, the AMQSPUT application was given a reason code, MQRC_Q_FULL (2053) so there is no requirement for the DLQ.

In your second example, the application that put the message to the remote has been given a zero return code at the point where the message lands on the transmission (Xmit) queue but then something happens downstream that fails. In this case, the zero return code means that MQ has already promised to look after this message, so it has to find somewhere safe to store it and in doing so also record the reason it failed. This is why it uses the DLQ.

You can read this blog post I wrote for more information: Dead-letter Queue use by IBM MQ Channels

There are other components in MQ that will use the DLQ, but the main point is that if there is an application to give a reason code back to then they don't need to.

Cheers,
Morag

Related Content