Wednesday, December 7, 2011

MQ: Skipping backout


As part of a unit of work, an application program can issue one or more MQGET
calls to get messages from a queue. If the application program detects an error, it can back out the unit of work. This restores all the resources updated during thatunit of work to the state they were in before the unit of work started, and reinstates the messages retrieved by the MQGET calls.

Once reinstated, these messages are available to subsequent MQGET calls issued
by the application program. In many cases, this does not cause a problem for the application program. However, in cases where the error leading to the backout cannot be circumvented, having the message reinstated on the queue can cause the application program to enter an ‘MQGET–error–backout’ loop.

To avoid this problem, specify the MQGMO_MARK_SKIP_BACKOUT option on
the MQGET call. This marks the MQGET request as not being involved in
application-initiated backout; that is, it should not be backed out. Use of this option means that when a backout occurs, updates to other resources are backed out as required, but the marked message is treated as if it had been retrieved under a new unit of work.

The application can now perform appropriate error handling (such as sending a report message to the sender of the original message, or placing the original message on the dead-letter queue), and then commit the new unit of work. Committing the new unit of work causes the message to be removed permanently from the original queue.If the new unit of work is backed out (for any reason) the message is reinstated on the queue.

Within a unit of work, there can be only one MQGET request marked as skipping
backout; however, there can be several other messages that are not marked as
skipping backout. Once a message has been marked as skipping backout, any
further MQGET calls within the unit of work that specify
MQGMO_MARK_SKIP_BACKOUT will fail with reason code
MQRC_SECOND_MARK_NOT_ALLOWED.

This option has an effect only if the unit of work containing the get request is terminated by the application backing it out. (Such requests use calls or commands that depend on the environment.) This option has no effect if
the unit of work containing the get request is backed out for any other
reason (for example, because the transaction or system abends). In this
situation, any message retrieved using this option is reinstated on the
queue in the same way as messages retrieved without this option.

A CICS application that backs out a unit of work containing a message retrieved with the MQGMO_MARK_SKIP_BACKOUT option must issue an MQ call (any MQ call will do) before committing or backing out the new unit of work.


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.