Filter
Top Products
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.
Retrying backout-failed units of work
Backout retry for a backout-failed data set either can be driven manually (using the
SET DSNAME RETRY command) or in many situations occurs automatically when the
cause of the failure has been resolved.
When CICS performs backout retry for a data set, any backout-failed units of work
that are shunted because of backout failures on that data set are unshunted, and
the recovery manager passes the log records for that data set to file control. File
control attempts to back out the updates represented by the log records and, if the
original cause of the backout failure is now resolved, the backout retry succeeds. If
the cause of a backout failure is not resolved, the backout fails again, and backout
failure support is reinvoked.
Disposition of data sets after backout failures
Because individual records are locked when a backout failure occurs, CICS need
not set the entire data set into a backout-failed condition.
CICS may be able to continue using the data set, with only the locked records
being unavailable. Some kinds of backout failure can be corrected without any
need to take the data set offline (that is, without needing to stop all current use of
the data set and prevent further access). Even for those failures that cannot be
corrected with the data set online, it may still be preferable to schedule the repair
at some future time and to continue to use the data set in the meantime, if this is
possible.
Possible reasons for VSAM backout failure
There are many reasons why back out can fail, and these are described in this
topic. In general, each of these descriptions corresponds with a REASON returned
on an INQUIRE UOWDSNFAIL command.
I/O error
You must take the data set offline to repair it, but there may be occasions when
the problem is localized and use of the data set can continue until it is
convenient to carry out the repair.
Message DFHFC4701 with a failure code of X'24' indicates that an I/O error (a
physical media error) has occurred while backing out a VSAM data set. This
indicates that there is some problem with the data set, but it may be that the
problem is localized. A better indication of the state of a data set is given by
message DFHFC0157 (followed by DFHFC0158), which CICS issues whenever
an I/O error occurs (not just during backout). Depending on the data set
concerned, and other factors, your policy may be to repair the data set:
v After a few I/O errors
v After the first backout failure
v After a number of I/O errors that you consider to be significant
v After a significant number of backout failures
v Not at all
80 CICS TS for z/OS 4.1: Recovery and Restart Guide