When the operator replies to IXC402D, the CICS interregion communication
program, DFHIRP, is notified and the suspended tasks are abended, and MRO
connections closed. Until the reply is issued to IXC402D, an INQUIRE
CONNECTION command continues to show connections to regions in the failed
MVS as in service and normal.
When the failed MVS image and its CICS regions are restarted, the interregion
communication links are reopened automatically.
CICS recovery processing following a transaction failure
Transactions can fail for a variety of reasons, including a program check in an
application program, an invalid request from an application that causes an abend,
a task issuing an ABEND request, or I/O errors on a data set that is being accessed
by a transaction.
During normal execution of a transaction working with recoverable resources,
CICS stores recovery information in the system log. If the transaction fails, CICS
uses the information from the system log to back out the changes made by the
interrupted unit of work. Recoverable resources are thus not left in a partially
updated or inconsistent state. Backing out an individual transaction is called
dynamic transaction backout.
After dynamic transaction backout has completed, the transaction can restart
automatically without the operator being aware of it happening. This function is
especially useful in those cases where the cause of transaction failure is temporary
and an attempt to rerun the transaction is likely to succeed (for example, DL/I
program isolation deadlock). The conditions when a transaction can be
automatically restarted are described under “Abnormal termination of a task” on
page 93.
If dynamic transaction backout fails, perhaps because of an I/O error on a VSAM
data set, CICS backout failure processing shunts the unit of work and converts the
locks that are held on the backout-failed records into retained locks. The data set
remains open for use, allowing the shunted unit of work to be retried. If backout
keeps failing because the data set is damaged, you can create a new data set using
a backup copy and then perform forward recovery, using a utility such as CICSVR.
When the data set is recovered, retry the shunted unit of work to complete the
failed backout and release the locks.
Chapter 8, “Unit of work recovery and abend processing,” on page 73 gives more
details about CICS processing of a transaction failure.
CICS recovery processing following a system failure
Causes of a system failure include a processor failure, the loss of a electrical power
supply, an operating system failure, or a CICS failure.
During normal execution, CICS stores recovery information on its system log
stream, which is managed by the MVS system logger. If you specify
START=AUTO, CICS automatically performs an emergency restart when it restarts
after a system failure.
During an emergency restart, the CICS log manager reads the system log backward
and passes information to the CICS recovery manager.
10 CICS TS for z/OS 4.1: Recovery and Restart Guide