Backout-failed recovery

Backout failure support is currently provided only by CICS® file control.

If backout to a VSAM data set fails for any reason, CICS performs the following processing:
  • Invokes the backout failure global user exit program at XFCBFAIL, if this exit is enabled. If the user exit program chooses to bypass backout failure processing, the remaining actions listed here are not taken.
  • Issues message DFHFC4701, giving details of the update that has failed backout, and the type of backout failure that has occurred.
  • Converts the active exclusive locks into retained locks. This ensures that no other task in any CICS region (including the region that owns the locks) waits for a lock that cannot be granted until the failure is resolved. (In this situation, CICS returns the LOCKED condition to other tasks that request a lock.) Preserving locks in this way also prevents other tasks from updating the records until the failure is resolved.
    • For data sets open in RLS mode, CICS requests SMSVSAM to retain the locks.
    • For VSAM data sets open in non-RLS mode, the CICS enqueue domain provides an equivalent function.
    Creating retained locks also ensures that other requests do not have to wait on the locks until the backout completes successfully.
  • Keeps the log records that failed to be backed out (by shunting the unit of work) so that the failed records can be presented to file control again when backout is retried. (See Shunted units of work for more information about shunted units of work.

If a unit of work updates more than one data set, the backout might fail for only one, or some, of the data sets. When this occurs, CICS converts to retained locks only those locks held by the unit of work for the data sets for which backout has failed. When the unit of work is shunted, CICS releases the locks for records in data sets that are backed out successfully. The log records for the updates made to the data sets that fail backout are kept for the subsequent backout retry. CICS does not keep the log records that are successfully backed out.

For a given data set, it is not possible for some of the records updated by a unit of work to fail backout and for other records not to fail. For example, if a unit of work updates several records in the same data set, and backout of one record fails, they are all deemed to have failed backout. The backout failure exit is invoked once only within a unit of work, and the backout failure message is issued once only, for each data set that fails backout. However, if the backout is retried and fails again, the exit is reinvoked and the message is issued again.

For BDAM data sets, there is only limited backout failure support: the backout failure exit, XFCBFAIL, is invoked (if enabled) to take installation-defined action, and message DFHFC4702 is issued.

Auxiliary temporary storage

All updates to recoverable auxiliary temporary storage queues are managed in main storage until syncpoint. TS always commits forwards; therefore TS can never suffer a backout failure.

Transient data

All updates to logically recoverable intrapartition queues are managed in main storage until syncpoint, or until a buffer must be flushed because all buffers are in use. TD always commits forwards; therefore, TD can never suffer a backout failure on DFHINTRA.