Filter
Top Products
See “Commit-failed recovery” on page 83.
Backout-failed
A unit of work fails while backing out updates to file control recoverable
resources. (The concept of backout-failed applies in principle to any
resource that performs backout recovery, but CICS file control is the only
resource manager to provide backout failure support.) A partial copy of the
unit of work is shunted to await retry of the backout process when the
problem is resolved.
Note: Although the failed backout may have been attempted as a result of
the abnormal termination of a transaction, the backout failure itself does
not cause the transaction to terminate abnormally.
For example, if a transaction initiates backout through an EXEC CICS
SYNCPOINT ROLLBACK command, CICS returns a normal response (not
an exception condition) and the transaction continues executing. It is up to
recovery manager to ensure that locks are preserved until backout is
eventually completed.
If some resources involved in a unit of work are backout-failed, while
others are commit-failed, the UOW as a whole is flagged as backout-failed.
See “Backout-failed recovery” on page 79.
Indoubt-failed
A distributed unit of work fails while in the indoubt state of the two-phase
commit process. The transaction is abnormally terminated. If there are
normally more units of work that follow the one that failed indoubt, these
will not be executed as a result of the abend.
A partial copy of the unit of work is shunted to await resynchronization
when CICS re-establishes communication with its coordinator. This action
happens only when the transaction resource definition specifies that units
of work are to wait in the event of failure while indoubt. If they are
defined with WAIT(NO), CICS takes the action specified on the ACTION
parameter, and the unit of work cannot become failed indoubt.
See “Indoubt failure recovery” on page 84.
Transaction backout
If the resources updated by a failed unit of work are defined as recoverable, CICS
automatically performs transaction backout of all uncommitted changes to the
recoverable resources.
Transaction backout is mandatory and automatic - there is not an option on the
transaction resource definition allowing you to control this. You can, however,
control backout of the resources on which your transactions operate by defining
whether or not they are recoverable.
In transaction backout, CICS restores the resources specified as recoverable to the
state they were in at the beginning of the interrupted unit of work (that is, at start
of task or completion of the most recent synchronization point). The resources are
thus restored to a consistent state.
In general, the same process of transaction backout is used for individual units of
work that abend while CICS is running and for in-flight tasks recovered during
emergency restart. One difference is that dynamic backout of a single abnormally
74 CICS TS for z/OS 4.1: Recovery and Restart Guide