IBM SC34-7012-01 manual Tidy up any outstanding CICS recovery work, as follows

In these cases, you can resolve the cause of the failure and try the whole process again.

This topic describes what to do when the failure in forward recovery cannot be resolved. In this case, where you are unsuccessful in applying all the forward recovery log data to a restored backup, you are forced to abandon the forward recovery, and revert to your most recent full backup. For this situation, the access method services SHCDS command provides the FRDELETEUNBOUNDLOCKS subcommand, which allows you to delete the retained locks that were associated with the data set, instead of re-binding them to the recovered data set as in the case of a successful forward recovery.

The most likely cause of a forward recovery failure is the loss or corruption of one or more forward recovery logs. In this event, you probably have no alternative other than to restore the most recent backup and reapply lost updates to the data set manually. In this case, it is important that you force CICS to discard any pending (shunted) units of work for the data set that has failed forward recovery before you restore the most recent backup. This is because, during recovery processing, CICS assumes that it is operating on a data set that has been correctly forward recovered.

CICS performs most of its recovery processing automatically, either when the region is restarted, or when files are opened, or when a data set is unquiesced. There isn't any way that you can be sure of preventing CICS from attempting this recovery processing. How you force recovery processing before restoring the backup depends on whether or not the affected CICS regions are still running:

vFor a CICS region that is still running, issue the appropriate CICS commands to initiate the retry of pending units of work.

vFor a CICS region that is shut down, restart it to cause CICS to retry automatically any pending units of work.

Note: Ensure you issue any CICS commands, or restart a CICS region, before you restore the most recent backup, otherwise CICS will perform recovery processing against the restored data set, which you don't want.

In the event of a failed forward recovery of a data set, use the following procedure:

1.Tidy up any outstanding CICS recovery work, as follows:

a.Make sure that any CICS regions that are not running, and which could have updated the data set, are restarted to enable emergency restart processing to drive outstanding backouts.

b.Using information returned from the INQUIRE UOWDSNFAIL command issued in each CICS region that uses the data set, compile a list of all shunted UOWs that hold locks on the data set.

c.If there are shunted indoubt units of work, try to resolve the in-doubts before proceeding to the next step. This is because the indoubt units of work may have updated resources other than the failed data set, and you don’t want to corrupt these other resources.

If the resolution of an indoubt unit of work results in backout, this will fail for the data set that is being restored, because it is still in a recovery-required state. The (later) step to reset locks for backout-failed UOWs allows you to tidy up any such backout failures that are generated by the resolution of in-doubts.

d.In all CICS regions that could have updated the failed data set:

Chapter 17. Forward recovery procedures 199