Filter
Top Products
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:
v It 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.
v CICS 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.
v CICS 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.
v For 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
90 CICS TS for z/OS 4.1: Recovery and Restart Guide