Recovering IMS units of recovery manually

Use this topic to understand what happens when the IMS adapter restarts, and then explains how to deal with any unresolved units of recovery that arise.


What happens when the IMS adapter restarts

Whenever the connection to IBM MQ is restarted, either following a queue manager restart or an IMS /START SUBSYS command, IMS initiates the following resynchronization process:
  1. IMS presents the list of unit of work (UOW) IDs that it believes are in doubt to the IBM MQ IMS adapter one at a time with a resolution parameter of Commit or Backout.
  2. The IMS adapter passes the resolution request to IBM MQ and reports the result back to IMS.
  3. Having processed all the IMS resolution requests, the IMS adapter gets from IBM MQ a list of all UOWs that IBM MQ still holds in doubt that were initiated by the IMS system. These are reported to the IMS master terminal in message CSQQ008I.

Note: While a UOW is in doubt, any associated IBM MQ message is locked by IBM MQ and is not available to any application.


How to resolve IMS units of recovery manually

When IMS connects to IBM MQ, IBM MQ might have one, or more in-doubt units of recovery that have not been resolved.

If IBM 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-name

If 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 IBM 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 IBM MQ resources.
  • Some IBM 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. We must be aware of this potential difficulty, and we must 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:
    1. 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.
    2. 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 affect the rest of the processing and the rest of the message queues.
    3. Produce a list of the in-doubt units of recovery from IBM 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.

    4. 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.
    5. Perform in-doubt resolution in IBM MQ with the RESOLVE INDOUBT command, as follows:
      RESOLVE INDOUBT( connection-name )
      ACTION(COMMIT|BACKOUT)
      NID( network-id )
      

    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 SCHEDULED
    

    When performing in-doubt resolution, IMS and the adapter are not aware of the commands to IBM MQ to commit or back out in-doubt units of recovery because only IBM MQ resources are affected.

Parent topic: Recovering units of work manually