CICS backward recovery (backout)

Backward recovery, or backout, is a way of undoing changes made to resources such as files or databases.

Backout is one of the fundamental recovery mechanisms of CICS®. It relies on recovery information recorded while CICS and its transactions are running normally.

Before a change is made to a resource, the recovery information for backout, in the form of a before-image, is recorded on the CICS system log. A before-image is a record of what the resource was like before the change. These before-images are used by CICS to perform backout in two situations:

Note:
Although these occur in different situations, CICS uses the same backout process in each case--CICS does not distinguish between dynamic backout and emergency restart backout. See CICS emergency restart for an explanation of how CICS reattaches failed in-flight units of work in order to perform transaction backout following an emergency restart.

Each CICS region has only one system log, which cannot be shared with any other CICS region. The system log is written to a unique MVS™ system logger log stream. The CICS system log is intended for use only for recovery purposes--for example, during dynamic transaction backout, or during emergency restart. It is not meant to be used for any other purpose.

Note:
CICS actually supports two physical log streams--a primary and a secondary log stream. CICS uses the secondary log stream for storing log records of failed units of work, and also some long running tasks that have not caused any data to be written to the log for two complete activity key points. Failed units of work are moved from the primary to the secondary log stream at the next activity keypoint. Logically, both the primary and secondary log stream form one log, and as a general rule are simply referred to as the system log.

Dynamic transaction backout

In the event of a transaction failure (or if an application explicitly requests a syncpoint rollback), the CICS recovery manager uses the system log data to drive the resource managers to back out any updates made by the current UOW. (See Unit of work concepts for a description of units of work.) This process, known as dynamic transaction backout, takes place while the rest of CICS continues normally.

For example, when any updates made to a recoverable data set are to be backed out, file control uses the system log records to reverse the updates. When all the updates made in the unit of work have been backed out, the unit of work is completed. The locks held on the updated records are freed if the backout is successful.

For data sets open in RLS mode, CICS requests VSAM RLS to release the locks; for data sets open in non-RLS mode, the CICS enqueue domain releases the locks automatically.

Emergency restart backout

If a CICS region fails, you restart CICS with an emergency restart to back out any transactions that were in-flight at the time of failure.

During emergency restart, the recovery manager uses the system log data to drive backout processing for any UOWs that were in-flight at the time of the failure. The backout of UOWs during emergency restart is the same as a dynamic backout; there is no distinction between the backout that takes place at emergency restart and that which takes place at any other time. At this point, while recovery processing continues, CICS is ready to accept new work for normal processing.

The recovery manager also drives:

See Unit of work recovery for an explanation of the terms "commit-failed" and "backout-failed".

The recovery manager drives these backout and commit processes because the condition that caused them to fail may be resolved by the time CICS restarts. If the condition that caused a failure has not been resolved, the UOW remains in backout- or commit-failed state. See Backout-failed recovery and Commit-failed recovery for more information.

[[ Contents Previous Page | Next Page Index ]]