Messages that are backed out

When processing messages from a queue under the control of a unit of work, the unit of work can consist of one or more messages. If a backout occurs, the messages that were retrieved from the queue are reinstated on the queue, and they can be processed again in another unit of work. If the processing of a particular message is causing the problem, the unit of work is backed out again. This can cause a processing loop. Messages that were put to a queue are removed from the queue.

An application can detect messages that are caught up in such a loop by testing the BackoutCount field of MQMD. The application can either correct the situation, or issue a warning to an operator.

The backout count always survives restarts of the queue manager. Any change to the HardenGetBackout attribute is ignored.

For shared queues, the backout count always survives restarts of the queue manager. For all other configurations on z/OS, to ensure that the backout count for private queues survives restarts of the queue manager, set the HardenGetBackout attribute to MQQA_BACKOUT_HARDENED; otherwise, if the queue manager has to restart, it does not maintain an accurate backout count for each message. Setting the attribute this way adds the cost of extra processing.

For more information on committing and backing out messages, see Committing and backing out units of work.