IBM SC34-7012-01 manual Force shunted indoubt units of work using SET DSNAME

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.

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