Filter
Top Products
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:
v For a CICS region that is still running, issue the appropriate CICS commands to
initiate the retry of pending units of work.
v For 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