Error handling by the CICS-WebSphere MQ bridge

The CICS-WebSphere MQ bridge backs out units of work and issues a message in the event of an error.

Errors detected by the CICS-WebSphere MQ bridge cause the bridge to perform these actions:
  • Back out the unit of work.
  • If the request queue has a backout threshold (BOTHRESH) specified, the request is reprocessed until it succeeds, or the backout count exceeds the threshold. You are not recommended to specify a backout threshold, unless you think that an immediate retry will be successful.
  • Move request messages to the backout requeue queue, if defined, or the dead-letter queue. Messages with report option MQRO_DISCARD are not written to the dead-letter queue.
  • Send an error reply message back to the client if a reply-to queue is available.
  • Write a DFHMQ7nn message:
    • To the CICS® CSMT transient data queue
    • To the CICS joblog
    • To both
  • Instead of writing a DFHMQ7nn message, the bridge might issue a transaction abend. Where it is possible to put a message on the reply-to queue, the message contains this abend code.
Any further request messages in the same unit of work are removed from the request queue and copied to the backout requeue or dead-letter queue, either during error processing for this unit of work or at the next initialization of the monitor. No further error messages are generated.

If sending a reply message fails, the CICS-WebSphere MQ bridge puts the reply on the dead-letter queue, passing identity context from the CICS-WebSphere MQ bridge request queue. A unit of work is not backed out if the reply message is successfully put on the dead-letter queue. Failure to put a reply message on the dead-letter queue is treated as a request error and the unit of work is backed out.

If the CICS-WebSphere MQ bridge fails to put a request message on the dead-letter queue, the CICS-WebSphere MQ bridge task abends and leaves the CICS-WebSphere MQ bridge monitor to process the error. If the monitor fails to move a persistent request message to the dead-letter queue, the monitor leaves the message on the request queue. Nonpersistent messages are discarded .

Failure to put an error reply is ignored by the CICS-WebSphere MQ bridge. The request message has already been copied to the dead-letter queue and the unit of work has been backed out by WebSphere® MQ.

Figure 1 shows what happens when an error occurs in a unit of work.
Figure 1. User program abends (only program in the unit of work)
The text following the figure describes the figure fully.

In this figure, the client application sends a request message to run a CICS program named P1. The queue manager used by the client receives the message.

The CICS-WebSphere MQ bridge monitor browses the request queue waiting for the arrival of a message. When a message arrives, the monitor task performs these actions:
  1. Gets the request message with browse
  2. Checks for any problems with the request message
  3. Starts a CICS-WebSphere MQ bridge task
  4. Continues browsing the request queue
The CICS-WebSphere MQ bridge task performs these actions:
  1. Gets the request message from the request queue under sync point control
  2. Takes the information in the request message and builds a COMMAREA for program P1
  3. Issues an EXEC CICS LINK call to program P1
  4. Waits for program P1 to complete
When these tasks are complete, the user program abends.
The CICS-WebSphere MQ bridge task abend handler is driven. It performs these actions:
  1. Issues an EXEC CICS SYNCPOINT ROLLBACKcommand, which backs out all the changes made by P1 and reinstates the request message on the request queue
  2. Gets the request message a second time from the request queue, again under sync point control
  3. Copies the request to the dead-letter queue
  4. Puts an error reply to the reply-to queue

If the request message includes the name of a reply-to queue, the abend handler writes a DFHMQ7nn message to the CICS-WebSphere MQ CSMT transient data queue.