What happens when the CICS-WebSphere MQ adapter restarts

Whenever a connection is broken, the adapter must go through a restart phase during the reconnect process. The restart phase resynchronizes resources. Resynchronization between CICS® and WebSphere® MQ enables indoubt units of work to be identified and resolved.

Resynchronization can be caused by these requests:
  • An explicit request from the distributed queuing component
  • An implicit request when a connection is made to WebSphere MQ
If the resynchronization is caused by connecting to WebSphere MQ, the sequence of events is as follows:
  1. The connection process obtains a list of unit of work (UOW) IDs that WebSphere MQ thinks are indoubt.
  2. The UOW IDs are displayed on the console in DFHMQ0313I messages.
  3. The UOW IDs are passed to CICS.
  4. CICS initiates a resynchronization task (CRSY) for each indoubt UOW ID.
  5. The result of the task for each indoubt UOW is displayed on the console.
You need to check the messages that are displayed during the connect process:
DFHMQ0313I
Shows that a UOW is in doubt.
DFHMQ0400I
Identifies the UOW and is followed by one of these messages:
  • DFHMQ0402I or DFHMQ0403I shows that the UOW was resolved successfully (committed or backed out).
  • DFHMQ0404E, DFHMQ0405E, DFHMQ0406E, or DFHMQ0407E shows that the UOW was not resolved.
DFHMQ0409I
Shows that all UOWs were resolved successfully.
DFHMQ0408I
Shows that not all UOWs were resolved successfully.
DFHMQ0314I
Warns that UOW IDs highlighted with a * are not resolved automatically. These UOWs must be resolved explicitly by the distributed queuing component when it is restarted.

The total number of DFHMQ0313I messages should equal the total number of DFHMQ0402I plus DFHMQ0403I messages. If the totals are not equal, the connection process cannot resolve some UOWs. Those UOWs that cannot be resolved are caused by problems with CICS (for example, a cold start) or with WebSphere MQ, or by distributing queuing. When these problems have been fixed, you can initiate another resynchronization by disconnecting and then reconnecting.

Alternatively, you can resolve each outstanding UOW yourself using the RESOLVE INDOUBT command and the UOW ID shown in message DFHMQ0400I. You must then initiate a disconnect and a connect to clean up the unit of work descriptors in CICS. You must know the correct outcome of the UOW to resolve UOWs manually.

All messages that are associated with unresolved UOWs are locked by WebSphere MQ and no Batch, TSO, or CICS task can access them.

If CICS fails and an emergency restart is necessary, do not vary the GENERIC APPLID of the CICS system. If you do, and then reconnect to WebSphere MQ, data integrity with WebSphere MQ cannot be guaranteed, because WebSphere MQ treats the new instance of CICS as a different CICS (because the APPLID is different). Indoubt resolution is then based on the wrong CICS log.

Do not change the setting for RESYNCMEMBER when units of work are outstanding in WebSphere MQ as this means that the units of work cannot be resolved. A unit of work held in CICS is identified with a resource manager qualifier. When RESYNCMEMBER(GROUPRESYNC) is used the qualifier is the name of the queue-sharing group, otherwise the qualifier used is the name of the individual queue manager.