IBM SC34-7012-01 manual Transaction backout, Backout-failed, Indoubt-failed

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

74CICS TS for z/OS 4.1: Recovery and Restart Guide