Filter
Top Products
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:
v 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 below are not taken.
v Issues message DFHFC4701, giving details of the update that has failed backout,
and the type of backout failure that has occurred.
v 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.
v 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” on page 13 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.
Chapter 8. Unit of work recovery and abend processing 79