1) Force shunted indoubt units of work using SET DSNAME(...)
UOWACTION(COMMIT | BACKOUT | FORCE).
Before issuing the next command, wait until the SET DSNAME(...)
UOWACTION has completed against all shunted indoubt units of work.
If the UOWACTION command for 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 (next) 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.
2) Reset locks for backout-failed units of work using SET DSNAME(...)
RESETLOCKS.
Do not issue this command until the previous UOWACTION command
has completed. RESETLOCKS operates only on backout-failed units of
work, and does not affect units of work that are in the process of being
backed out. If you issue RESETLOCKS too soon, and shunted indoubt
units of work fail during backout, the data set will be left with recovery
work pending.
The DFH0BAT3 sample program provides an example of how you can do
this.
There should not now be any shunted units of work on any CICS region
with locks on the data set.
2. When you are sure that all CICS regions have completed any recovery work for
the data set, delete the unbound locks using SHCDS
FRDELETEUNBOUNDLOCKS.
Note: It is very important to enter this command (and the following SHCDS
FRRESETRR) at this stage in the procedure. If you do not, and the failed data
set was in a lost locks condition, the data set will remain in a lost locks
condition unless you cold start all CICS regions which have accessed it. If you
mistakenly issued this command before step 1 of the procedure, then the
problem concerning lost locks will still arise even if you issue the command
again at this stage.
3. Allow access to the data set again using SHCDS FRRESETRR (even if you use
CICSVR, you have to allow access manually if you have abandoned the
forward recovery).
4. Finally, restore the backup copy from which you intend to work.
If the restored data set is eligible for backup-while-open (BWO) processing, you
may need to reset the BWO attributes of the data set in the ICF catalog. This is
because the failed forward recovery may have left the data set in a
‘recovery-in-progress’ state. You can do this using the CEMT, or EXEC CICS, SET
DSNAME RECOVERED command.
If you do not follow this sequence of operations, the restored backup could be
corrupted by CICS backout operations.
All the parts of step 1 of the above procedure may also be appropriate in similar
situations where you do not want CICS to perform pending backouts. An example
of this might be before you convert an RLS SMS-managed data set to non-SMS
when it has retained locks, because the locks will be lost.
200 CICS TS for z/OS 4.1: Recovery and Restart Guide