Filter
Top Products
others. This can happen, for example, if two data sets are updated and the UOW
has to be backed out, and the following happens:
v One resource backs out successfully
v While committing this successful backout, the commit fails
v The other resource fails to back out
These events leave one data set commit-failed, and the other backout-failed. In this
situation, the overall status of the UOW is logged as backout-failed.
During emergency restart following a CICS failure, each UOW and its state is
reconstructed from the system log. If any UOW is in the backout-failed or
commit-failed state, CICS automatically retries the UOW to complete the backout
or commit.
Coordinating updates in distributed units of work
If the execution of a UOW is distributed across more than one system, the CICS
recovery manager (or their non-CICS equivalents) in each pair of connected
systems ensure that the effects of the distributed UOW are atomic.
Each CICS recovery manager (or its non-CICS equivalent) issues the requests
necessary to effect two-phase syncpoint processing to each of the connected
systems with which a UOW may be in conversation.
Note: In this context, the non-CICS equivalent of a CICS recovery manager could
be the recovery component of a database manager, such as DBCTL or DB2
®
,orany
equivalent function where one of a pair of connected systems is not CICS.
In each connected system in a network, the CICS recovery manager uses interfaces
to its local recovery manager connectors (RMCs) to communicate with partner
recovery managers. The RMCs are the communication resource managers (IPIC,
LU6.2, LU6.1, MRO, and RMI) which have the function of understanding the
transport protocols and constructing the flows between the connected systems.
As remote resources are accessed during UOW execution, the CICS recovery
manager keeps track of data describing the status of its end of the conversation
with that RMC. The CICS recovery manager also assumes responsibility for the
coordination of two-phase syncpoint processing for the RMC.
Managing indoubt units of work
During the syncpoint phases, for each RMC, the CICS recovery manager records
the changes in the status of the conversation, and also writes, on behalf of the
RMC, equivalent information to the system log.
If a session fails at any time during the running of a UOW, it is the RMC
responsibility to notify the CICS recovery manager, which takes appropriate action
with regard to the unit of work as a whole. If the failure occurs during syncpoint
processing, the CICS recovery manager may be in doubt and unable to determine
immediately how to complete the UOW. In this case, the CICS recovery manager
causes the UOW to be shunted awaiting UOW resolution, which follows
notification from its RMC of successful resynchronization on the failed session.
During emergency restart following a CICS failure, each UOW and its state is
reconstructed from the system log. If any UOW is in the indoubt state, it remains
shunted awaiting resolution.
20 CICS TS for z/OS 4.1: Recovery and Restart Guide
|
|
|
|
|