Locking (enqueuing on) resources in application programs

This topic describes locking (enqueuing) functions provided by CICS® (and access methods) to protect data integrity. There are two forms of locking:

  1. The implicit locking functions performed by CICS (or the access method) whenever your transactions issue a request to change data. These are described under:
  2. The explicit enqueuing function that you request by means of an EXEC CICS command. This is described under Explicit enqueuing (by the application programmer).
Note:
Locking (implicit or explicit) data resources protects data integrity in the event of a failure, but can affect performance if several tasks attempt to operate on the same data resource at the same time. The effect of locking on performance, however, is minimized by implementing applications with short UOWs, as discussed under Dividing transactions into units of work.

Implicit locking for files

This section first describes the implicit locking provided while nonrecoverable files are being updated. It then describes the extended locking actions when recoverable files are being updated.

Nonrecoverable files

For BDAM files that are nonrecoverable (that is, LOG=NO is specified in the FCT entry), CICS does not lock records that are being updated. By default, you get BDAM exclusive control, which operates on a physical block, is system wide, but lasts only until the update is complete. If a transaction reads a record for update under BDAM exclusive control, and the transaction subsequently decides not to change the data, it must release the BDAM exclusive control. To do this, issue an EXEC CICS UNLOCK command, which causes CICS to issue a RELEX macro.

If you don’t want BDAM exclusive control, specify SERVREQ=NOEXCTL on the file entry in the FCT.

For nonrecoverable VSAM files accessed in non-RLS mode, VSAM exclusive control locks the control interval during an update. For nonrecoverable VSAM files accessed in RLS mode, SMSVSAM locks the record during the update.

Figure 13 illustrates the extent of locking for nonrecoverable files.

Figure 13. Locking during updates to nonrecoverable files. This figure illustrates two tasks updating the same record or control interval. Task A is given a lock on the record or control interval between the READ UPDATE and WRITE commands. During this period, task B waits.
 The diagram shows task A and Task B running concurrently. Task A issues a READ for UPDATE command against a nonrecoverable file, but before it can rewrite the record, task B also issues a READ for UPDATE against the same file for a record in the same control interval. The diagram shows task B in a wait state until task A rewrites the record and releases the lock. Task B is then given a lock for the duration of its update request. The diagram illustrates that locks are held only until the updated records are written back to the file.

Figure 14. Locking (enqueuing on a resource) during updates to recoverable files. This figure illustrates two tasks updating the same record or control interval. Task A is given an exclusive lock on the record until the update is committed (at the end of the UOW). During this period, task B waits.
 The diagram shows task A and Task B running concurrently. Task A issues a READ for UPDATE command against a recoverable file, but before it can rewrite the record, task B also issues a READ for UPDATE against the same file for a record in the same control interval. Task B has to wait because of the lock held by task A. Task A rewrites the updated record, but the diagram shows task B continuing to wait until task A reaches the end of its unit of work, when the update is committed and lock released. Task B is then given a lock which lasts until the end of its unit of work.

Recoverable files

For VSAM or BDAM files designated as recoverable, the duration of the locking action is extended as shown in Figure 14. For VSAM files, the extended locking is on the updated record only, not the whole control interval.

The extended period of locking is needed to avoid an update committed by one task being backed out by another. (Consider what could happen if the nonextended locking action shown in Figure 13 was used when updating a recoverable file. If task A abends just after task B has reached syncpoint and has thus committed its changes, the subsequent backout of task A returns the file to the state it was in at the beginning of task A, and task B’s committed update is lost.)

To avoid this problem, whenever a transaction issues a command that changes a recoverable file (or reads from a recoverable file prior to update), CICS automatically locks the updated record until the change is committed (that is, until the end of the UOW). Thus in the above example, Task B would not be able to access the record until Task A had committed its change at the end of the UOW. Hence, it becomes impossible for Task B’s update to be lost by a backout of Task A. For files opened in non-RLS mode, CICS provides this locking using the enqueue domain. For files opened in RLS mode, SMSVSAM provides the locking, and the locks are released at the completion of the unit of work at the request of CICS.

The file control commands that invoke automatic locking in this way are:

Notes:
  1. Enqueuing as described above can lead to transaction deadlock (see Possibility of transaction deadlock).
  2. The scope of locks varies according to the access method, the type of access, and who obtains the lock:
    • BDAM exclusive control applies to the physical block
    • Non-RLS VSAM exclusive control applies to the control interval
    • CICS locks for BDAM (with NOEXCTL specified) apply to the record only
    • CICS locks for non-RLS VSAM apply to the record only
    • SMSVSAM locks for RLS apply to the record only
  3. VSAM exclusive control. The CICS enqueuing action on recoverable files opened in non-RLS mode lasts until the end of the UOW. When a transaction issues a READ UPDATE command, VSAM's exclusive control of the control interval containing the record is held only long enough for CICS to issue an ENQ on the record. CICS then notifies VSAM to release the exclusive control of the CI, and re-acquires this only when the task issues a REWRITE (or UNLOCK, DELETE, or SYNCPOINT) command. Releasing the VSAM exclusive CI lock until the task is ready to rewrite the record minimises the potential for transaction deadlock
  4. For recoverable files, do not use unique key alternate indexes (AIXs) to allocate unique resources (represented by the alternate key). If you do, backout may fail in the following set of circumstances:
    1. A task deletes or updates a record (through the base or another AIX) and the AIX key is changed.
    2. Before the end of the first task’s UOW, a second task inserts a new record with the original AIX key, or changes an existing AIX key to that of the original one.
    3. The first task fails and backout is attempted.
    The backout fails because a duplicate key is detected in the AIX indicated by message DFHFC4701, with a failure code of X'F0'. There is no locking on the AIX® key to prevent the second task taking the key before the end of the first task’s UOW. If there is an application requirement for this sort of operation, you should use the CICS enqueue mechanism to reserve the key until the end of the UOW.
  5. To ensure that the data being read is up-to-date, the application program should:
    • For files accessed in non-RLS mode, issue a READ UPDATE command (rather than a simple READ), thus locking the data until the end of the UOW
    • For files accessed in RLS mode, use the consistent read integrity option.

Implicit enqueuing on logically recoverable TD destinations

CICS provides an enqueuing protection facility for logically recoverable (as distinct from physically recoverable) transient data destinations in a similar way to that for recoverable files. There is one minor difference, however: CICS regards each recoverable destination as two separate recoverable resources--one for writing and one for reading.

Transient data control commands that invoke implicit enqueuing are:

Thus, for example:

Implicit enqueuing on recoverable temporary storage queues

CICS provides the enqueuing protection facility for recoverable temporary storage queues in a similar way to that for recoverable files on VSAM data sets. There is one minor difference, however: CICS enqueuing is not invoked for READQ TS commands, thereby making it possible for one task to read a temporary storage queue record while another is updating the same record. To avoid this, use explicit enqueuing on temporary storage queues where concurrently executing tasks can read and change queue(s) with the same temporary storage identifier. (See Explicit enqueuing (by the application programmer).)

Temporary storage control commands that invoke implicit enqueuing are:

Implicit enqueuing on DL/I databases with DBCTL

IMS™™ program isolation scheduling ensures that, when a task accesses a segment by a DL/I database call, it implicitly enqueues on all segments in the same database record as the accessed segment. How long it is enqueued depends on the access method being used:

The foregoing rules for program isolation scheduling can be overridden using the ‘Q’ command code in a segment search argument (this command extends enqueuing to the issue of a DL/I TERM call), or by using PROCOPT=EXCLUSIVE in the PCB (this macro gives exclusive control of specified segment types throughout the period that the task has scheduled the PSB).

Explicit enqueuing (by the application programmer)

CICS provides the following explicit enqueuing commands:

These commands can be useful in certain applications when, for example, you want to:

To be effective, however, all transactions must adhere to the same convention. A transaction that accesses the CWA without using the agreed ENQ and DEQ commands is not suspended, and protection is violated.

After a task has issued an ENQ RESOURCE(data-area) command, any other task that issues an ENQ RESOURCE command with the same data-area parameter is suspended until the task issues a matching DEQ RESOURCE(data-area) command, or until the UOW ends.

Note:
Enqueueing on more than one resource concurrently might create a deadlock between transactions.

Possibility of transaction deadlock

The enqueuing and program isolation scheduling mechanisms, which protect resources against double updating, can cause a situation known as transaction deadlock.9

As shown in Figure 15, transaction deadlock means that two (or more) tasks cannot proceed because each task is waiting for the release of a resource that is enqueued upon by the other. (The enqueuing, DL/I program isolation scheduling action, or VSAM RLS locking action protects resources until the next synchronization point is reached.)

Figure 15. Transaction deadlock (generalized)
 This diagram illustrates how two tasks, shown as task A and task B, are running concurrently and updating recoverable resources. The sequence is as follows: Task A updates resource 1, while at the same time task B updates resource 2. Continuing in the same units of of work, which means that locks are still held, A then attempts to update resource 2, while B attempts to update resource 1. The result is deadlock, with each task waiting on the other to release its lock.

If transaction deadlock occurs, one task abends and the other proceeds.

The abended task may then be backed out by dynamic transaction backout, as described in Transaction backout. (Under certain conditions, the transaction can be restarted automatically, as described under Abnormal termination of a task. Alternatively, the terminal operator may restart the abended transaction.)

For more information, see Designing to avoid transaction deadlock.


9.
Transaction deadlock is sometimes known as enqueue deadlock, enqueue interlock, or deadly embrace.

[[ Contents Previous Page | Next Page Index ]]