Remotely determined errors

When you send messages to a remote queue, even when the local queue manager has processed your MQI call without finding an error, other factors can influence how your message is handled by a remote queue manager.

For example, the queue that you are targeting might be full, or might not even exist. If your message has to be handled by other intermediate queue managers on the route to the target queue, any of these could find an error.

Problems delivering a message

When an MQPUT call fails, we can try to put the message on the queue again, return it to the sender, or put it on the dead-letter queue.

Each option has its merits, but you might not want to try putting a message again if the reason that the MQPUT failed was because the destination queue was full. In this instance, putting it on the dead-letter queue allows you to deliver it to the correct destination queue later on.

Retry message delivery

Before the message is put on a dead-letter queue, a remote queue manager attempts to put the message on the queue again if the attributes MsgRetryCount and MsgRetryInterval have been set for the channel, or if there is a retry exit program for it to use (the name of which is held in the channel attribute MsgRetryExitId field).

If the MsgRetryExitId field is blank, the values in the attributes MsgRetryCount and MsgRetryInterval are used.

If the MsgRetryExitId field is not blank, the exit program of this name runs. For more information about using your own exit programs, see Channel-exit programs for messaging channels.

Return message to sender

You return a message to the sender by requesting a report message to be generated to include all of the original message.

See Report messages for details on report message options.