IBM SC34-7012-01 manual A special case lost locks, Overriding retained locks, About this task

X’AA6DB08AC66B4000’ and file ACCNT1 .

Update was a write-add made by transaction WKLY at terminal T583 under task number 00027. Key length 4, data length 7, base ESDS RBA X’00000DDF’, record key X’00000DDF’

A special case: lost locks

If a lost locks condition occurs, any affected data set remains in a lost locks state until all CICS regions have completed lost locks recovery for the data set.

Lost locks recovery is complete when all uncommitted changes, which were protected by the locks that were lost, have been committed. Therefore, after a lost locks condition occurs, you may need to follow the same procedures as those for preparing for batch jobs (described in “The batch-enabling sample programs” on page 178), to ensure that the data set is made available again as soon as possible. Preserving data integrity should be the priority, but you may decide to force indoubt units of work and to reset locks in order to make the data set available sooner.

Overriding retained locks

There may be situations in which it is difficult or inconvenient to use CICS commands to remove all the retained locks held against a data set.

About this task

For these situations, DFSMS access method services provides a SHCDS subcommand that allows you to run a non-RLS batch program despite the fact that there are retained locks.

The PERMITNONRLSUPDATE subcommand

The SHCDS PERMITNONRLSUPDATE subcommand allows you to run a non-RLS batch job where it is not possible to resolve all the retained locks that are held against the data set.

This subcommand overrides the DFSMS controls that prevent non-RLS opens-for-update when a data set still has retained locks. Use this option only as a last resort.

The effect of the PERMITNONRLSUPDATE command is canceled as soon as the data set is re-opened in RLS mode after the batch work is complete. Re-issue the command when you next want to override retained locks.

The DENYNONRLSUPDATE subcommand

The SHCDS DENYNONRLSUPDATE subcommand allows you to reset the permit status of a data set to prevent non-RLS updates.

This subcommand is provided for the situation where you issue the PERMITNONRLSUPDATE subcommand in error, and want to turn the permit status off again without running any non-RLS work:

vSpecify DENYNONRLSUPDATE if you do not run a non-RLS batch job after specifying PERMITNONRLSUPDATE. This is because CICS, when it next opens the data set in RLS mode, takes action assuming that the data set has been opened for update in non-RLS mode if the PERMITNONRLSUPDATE state is set.

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