Indoubt units of work (UOWs) can occur when CICS®, DB2®, or the whole system fails whilst a transaction is carrying out syncpoint processing, that is, during processing of an EXEC CICS SYNCPOINT or EXEC CICS RETURN command. CICS is the coordinator of the UOW, and if more than one recoverable resource is involved uses the two-phase commit protocol when trying to commit the UOW. Between replying "yes" to the phase 1 prepare call, and before receiving the commit or backout call at phase 2 time, DB2 is indoubt as to the outcome of the UOW. If a failure occurs at this time, DB2 remains indoubt about the UOW; it has an indoubt UOW and must ask CICS to resynchronize.
In situations where only DB2 and a single CICS system are involved with the unit of work, CICS is always the coordinator. If further parties are involved--for example, by means of a LU6.2 communication link--it is possible that the local CICS system is not the overall coordinator of the unit of work; for example, a remote CICS system might be the coordinator instead. In this situation, it is possible that both DB2 and the local CICS system are indoubt about the outcome of the UOW. If a failure occurs in this situation, the local CICS system might shunt the unit of work, depending on the definition for the transaction. The unit of work is then considered to be shunted indoubt.
Indoubt UOWs are normally resolved automatically when the connection between CICS and DB2 is reestablished. CICS and DB2 exchange information regarding the indoubt UOWs; that is, CICS informs DB2 whether the UOW was backed out or committed. If a UOW is shunted indoubt, this exchange of information is deferred until the remote coordinator has informed CICS of the outcome. However, if you are using group attach, CICS might reconnect to a different DB2 subsystem, and be unable to exchange information about the indoubt UOWs held by the previously connected DB2 subsystem. The RESYNCMEMBER attribute of the DB2CONN definition is used to solve this problem--see Resolving indoubt UOWs when using group attach.
See Using the DB2 group attach facility for an explanation of how the DB2 group attach facility works. If you are using group attach and the connection between CICS and DB2 is broken, CICS might not reconnect to the same DB2 subsystem--it might choose a different member of the data-sharing group of DB2 subsystems. This means that if indoubt UOWs are being held by the first DB2 subsystem to which CICS connected, they cannot be resolved.
To solve this problem, CICS maintains a history of the last DB2 data-sharing group member to which it connected, which is cataloged and maintained across warm, emergency and cold starts (but not initial starts). During connection or reconnection to DB2, the CICS DB2 attachment facility checks this history to see if any outstanding UOW information is being held for the last DB2 data-sharing group member to which it connected, and acts as follows:
See the CICS Resource Definition Guide for information on setting RESYNCMEMBER. The RESYNCMEMBER option can also be set using a CEMT/EXEC CICS SET DB2CONN RESYNCMEMBER RESYNC/NORESYNC command--see CICS Supplied Transactions for the CEMT command, and the CICS System Programming Reference for the EXEC CICS command.
CICS supports the enhanced DB2 restart-light capability provided in DB2 Version 8. Restart-light mode is intended for a cross-system restart in the event of an MVS™ system failure, where the CICS systems are configured to use group attach (see Using the DB2 group attach facility). In DB2 Version 7, the DB2 restart-light capability allowed a DB2 data-sharing member to restart with a minimal storage footprint, free retained locks, and then terminate normally. However, this only applied to in-flight units of work, and not indoubt units of work. For DB2 Version 8, this capability was extended to encompass indoubt units of work. This enables a CICS system to connect to a DB2 restart-light subsystem for the purpose of resynchronizing indoubt units of work. This capability is especially useful because DB2 does not support peer recovery; that is, one DB2 subsystem cannot resynchronize indoubt units of work on behalf of another DB2 subsystem.
In a typical scenario, if an MVS LPAR fails, a cross-system restart can be initiated which involves restarting the failed CICS systems on another LPAR, and bringing up the failed DB2 subsystem on that LPAR in restart-light mode. Assume that the CICS systems have been configured to use group attach, with RESYNCMEMBER(YES) and STANDBYMODE(RECONNECT) on the DB2CONN definition, and there are indoubt units of work outstanding in DB2. The DB2 restart-light subsystem initializes, frees retained locks for any in-flight UOWs, and then awaits resynchronization with CICS for the indoubt UOWs. Each CICS system initializes, and detects whether it has outstanding units of work and whether RESYNCMEMBER(YES) has been specified. Where both these conditions are true, the CICS system ignores group attach and reconnects back to the last DB2 subsystem, which is the DB2 restart-light subsystem. The indoubt UOWs are now resynchronized, but no new transactions are allowed to access DB2. When all the indoubt UOWs have been resolved in the DB2 restart-light subsystem, it terminates. Because the CICS systems are defined with STANDBYMODE(RECONNECT), when the DB2 restart-light subsystem terminates, they drop into standby mode and attempt a reconnection to DB2. Now, because all the indoubt units of work have been resolved, RESYNCMEMBER does not apply and group attach can be used. The CICS systems will reconnect to a normal, active DB2 subsystem.
CICS maintains information about UOWs needed for resynchronization on its system log. Resynchronization information is maintained by CICS across warm, emergency, and cold starts. Resynchronization information is lost if an initial start of CICS is performed as the system log is initialized and all information is lost, deleting all information about previous units of work.
You should rarely need to initial start CICS. If you simply want to reinstall resources from the CSD, a cold start should be used, which allows any resynchronization information to be recovered. In particular, an initial start of CICS should be avoided if the previous warm shutdown of CICS issued message DFHRM0131 indicating that resynchronization is outstanding.
If CICS is initial started when DB2 resynchronization was required, when the CICS DB2 connection is re-established, message DFHDB2001 is output for each UOW that failed to be resynchronized, and the UOW must be resynchronized in DB2 using the DB2 RECOVER INDOUBT command. CICS Transaction Server has no equivalent to the DFH$INDB utility that was available in CICS/ESA Version 4 and earlier, which allowed scanning of the system log to ascertain the outcome of the UOW. The MVS system log, and hence all the UOW information on it, has been lost by initial starting of CICS .