IBM SC34-7012-01 manual Transient data, Retrying backout-failed units of work, I/O error

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-failedcondition.

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:

vAfter a few I/O errors

vAfter the first backout failure

vAfter a number of I/O errors that you consider to be significant

vAfter a significant number of backout failures

vNot at all

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