IBM SC34-7012-01 manual Performing lost locks recovery for failed units of work

region that was not sharing the data set at the time the lost locks condition occurred, and on RLS access requests issued by any new units of work in CICS regions that were sharing the data set.

Performing lost locks recovery for failed units of work

Lost locks recovery requires that any units of work that had been updating the data set at the time of the failure must complete before the data set can be made available for general use.

This is because their updates are no longer protected by the record locks, so access by other units of work and other CICS regions cannot be permitted until the updates have been either committed or backed out. Therefore, each CICS region performing lost locks recovery must complete all units of work before notifying VSAM that it has completed all affected units of work.

CICS takes the following actions during dynamic RLS restart to expedite lost locks recovery:

vIt drives backout-failed units of work for backout retry. If backout retry for a data set in the lost locks condition fails, lost locks recovery cannot complete until either:

–The backout is completed successfully (by resolving the condition that caused it), or

–The SET DSNAME RESETLOCKS command is used to abandon the backout, with consequent loss of data integrity.

vCICS drives commit-failed units of work for commit retry. Because the failure of an SMSVSAM server is the only cause of commit-failed units of work, retrying them succeeds when the server becomes available.

vCICS purges in-flight transactions that have updated a data set that is in a lost locks condition.

Following any failure of the SMSVSAM server, CICS abends and backs out any units of work that had made RLS requests before the failure, and which then attempt further RLS requests when the restarted SMSVSAM server is available, They are not backed out until they make a further request to RLS.

In the case of an SMSVSAM server failure that is caused by a lock structure failure, this would mean that in-flight units of work could delay the recovery from the lost locks condition until the units of work make further RLS updates. To avoid this potential delay, CICS purges the transactions to expedite lost locks recovery. CICS issues message DFHFC0171 if any in-flight transactions cannot be purged, warning that lost locks recovery could potentially be delayed.

vFor indoubt units of work that have updated a data set that is in a lost locks condition, CICS must wait for indoubt resolution before it can complete lost locks recovery, unless the unit of work is forced to complete using the SET DSNAME or SET UOW commands with the BACKOUT, COMMIT, or FORCE options. (See “Choosing data availability over data integrity” on page 177 for the reason why the BACKOUT option has advantages for UOWs that have updated CICS files.)

When a CICS region has completed lost locks recovery for a data set, it informs SMSVSAM. This is done once for each data set. When all CICS regions have informed SMSVSAM that they have completed their lost locks recovery for a particular data set, that data set is no longer in a lost locks condition, and is made available for general access. Although the lost locks condition affects

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