Undelivered messages
Specific scenarios related to server to server Message Channel Agent interception on IBM MQ for z/OS .
From IBM MQ Version 9.1.3, on IBM MQ for z/OS, if server to server Message Channel Agent (MCA) interception is in use:
- If, after having got and unprotected a message, the sender MCA fails to deliver a message for some reason, for example, because the message is too big for the channel, if the USEDLQ sender channel attribute is set to YES, the sender MCA moves the message to the local Dead Letter Queue (DLQ).If the SYSTEM.DEAD.LETTER.QUEUE is being used as the local DLQ, the message is placed unprotected.Note: IBM MQ AMS does not support the protection of messages put to system queues.
If a named DLQ is being used as the local DLQ, the message will be placed protected if you have defined an IBM MQ AMS policy with the same name as the named DLQ, and unprotected if you have not defined a suitable policy.
- If a message cannot be put to the local DLQ for some reason, then if the NPMSPEED of the channel is set to NORMAL, or the message is a persistent message, the current batch of messages is backed out and the channel put into RETRY state. Otherwise, the message is discarded and the sender MCA continues to process the next message on the transmission queue.
- Given that security policies have no effect on the SYSTEM.DEAD.LETTER.QUEUE, or the other SYSTEM queues listed in System queue protection in AMS, if the SYSTEM.DEAD.LETTER.QUEUE is in use, messages put to this queue by MCAs are placed as is. That is, if messages were previously protected, they are placed protected; otherwise, they are placed unprotected.
If the queue manager DEADQ attribute has been set to the name of an alternate (non-system) dead letter queue, and an AMS policy with the same name does not exist, messages put to this queue by MCAs are placed as is. That is, if messages were previously protected, they are placed protected; otherwise, they are placed unprotected.
If the queue manager DEADQ attribute has been set to the name of an alternate (non-system) dead letter queue and an AMS policy with the same name as the DLQ does exist, the policy is used to protect messages put to this queue by MCAs. If the message has previously already been protected, it is not protected again; this is to avoid double protection. If an AMS policy with the same name does not exist, messages are placed as-is.
- If there is a policy for the DLQ with the tolerate option in the setmqspl command set to off, that is '-t O', the put to the DLQ fails if the message is not AMS protected, and hence does not have a PDMQ header. This happens if the message arrives at the receiver without a PDMQ header. That is the original putter of the message did not have a policy for the destination, and the receiver does not have SPLPROT(ASPOLICY) set.
- An MCA might fail to put a message to the DLQ, if the AMS policy defined for the DLQ does not permit the user ID that the channel initiator is running under to protect the message.
- Receiver channels generally place undelivered messages to the local DLQ, while sender channels generally place messages that cannot be processed for some reason, for example, message too large for queue, or bad MQXQH header, and so on to the local DLQ.
- DLQ handlers generally only look at the DLQ header (DLH) and not the message payload itself. So, the fact that the message payload might be protected, does not prevent handlers from determining why the message was placed on the DLQ.
- If a DLQ is not defined, the channel:
- Ends abnormally (and goes into retrying state) if a persistent message cannot be delivered.
- Discards a non-persistent undelivered message, and continues to run.
Parent topic: Error handling
Related concepts