recovery, recovering manually, unit of recovery, in-doubt units of recovery, IMS units of recovery, units of recovery in IMS, displaying, CSQM201 message, NID (network ID), RESOLVE INDOUBT, WebSphere MQ commands" />
How to resolve IMS units of recovery manually
When IMS connects to WebSphere MQ, WebSphere MQ might have one or more in-doubt units of recovery that have not been resolved.
If WebSphere MQ has in-doubt units of recovery that IMS did not resolve, the following message is issued at the IMS master terminal:
CSQQ008I nn units of recovery are still in doubt in queue manager qmgr-nameIf this message is issued, IMS was either cold-started or it was started with an incomplete log tape. This message can also be issued if WebSphere MQ or IMS terminates abnormally because of a software error or other subsystem failure.
After receiving the CSQQ008I message:
- The connection remains active.
- IMS applications can still access WebSphere MQ resources.
- Some WebSphere MQ resources remain locked out.
If the in-doubt thread is not resolved, IMS message queues can start to build up. If the IMS queues fill to capacity, IMS terminates. You must be aware of this potential difficulty, and monitor IMS until the in-doubt units of recovery are fully resolved.
Recovery procedure
Use the following procedure to recover the IMS units of work:
- Force the IMS log closed, using /SWI OLDS, and then archive the IMS log. Use the utility, DFSERA10, to print the records from the previous IMS log tape. Type X'3730' log records indicate a phase-2 commit request and type X'38' log records indicate an abort request. Record the requested action for the last transaction in each dependent region.
- Run the DL/I batch job to back out each PSB involved that has not reached a commit point. The process might take some time because transactions are still being processed. It might also lock up a number of records, which could impact the rest of the processing and the rest of the message queues.
- Produce a list of the in-doubt units of recovery from WebSphere MQ using the following command:
+CSQ1 DISPLAY CONN(*) WHERE(UOWSTATE EQ UNRESOLVED)You receive the following message:
CSQM201I +CSQ1 CSQMDRTC DISPLAY CONN DETAILS CONN(BC45A794C4290001) EXTCONN(C3E2D8C3E2C5C3F24040404040404040) TYPE(CONN) CONNOPTS( MQCNO_STANDARD_BINDING ) UOWLOGDA(2005-02-15) UOWLOGTI(16.39.43) UOWSTDA(2005-02-15) UOWSTTI(16.39.43) UOWSTATE(UNRESOLVED) NID(IM8F .BC45A794D3810344) EXTURID( 0000052900000000 ) QMURID(00000354B76E) URTYPE(IMS) USERID(STCPI) APPLTAG(IM8F) ASID(0000) APPLTYPE(IMS) PSTID(0004) PSBNAME(GP01MPP)For IMS, the NID consists of the IMS connection name and a unique number provided by IMS. The value is referred to in IMS as the recovery token. For more information, see the IMS Customization Guide.
- Compare the NIDs (IMSID plus OASN in hexadecimal) displayed in the DISPLAY THREAD messages with the OASNs (4 bytes decimal) shown in the DFSERA10 output. Decide whether to commit or back out.
- Perform in-doubt resolution in WebSphere MQ with the RESOLVE INDOUBT command, as follows:
RESOLVE INDOUBT(connection-name) ACTION(COMMIT|BACKOUT) NID(network-id)
For information about the RESOLVE INDOUBT command, see the WebSphere MQ Script (MQSC) Command Reference manual.
To recover all threads associated with connection-name, use the NID(*) option. The command results in one of the following messages to indicate whether the thread is committed or backed out:
CSQV414I THREAD network-id COMMIT SCHEDULED CSQV415I THREAD network-id BACKOUT SCHEDULEDWhen performing in-doubt resolution, IMS and the adapter are not aware of the commands to WebSphere MQ to commit or back out in-doubt units of recovery because only WebSphere MQ resources are affected.