Files opened in RLS mode can be accessed by many CICS® regions simultaneously. This means it is impractical for the individual CICS regions to attempt to control record locking, and therefore VSAM maintains a single central lock structure using the lock-assist mechanism of the MVS™ coupling facility. This central lock structure provides sysplex-wide locking at a record level--control interval (CI) locking is not used. This is in contrast to the locks for files in non-RLS mode, the scope of which is limited to a single CICS region, and that are either CI locks or CICS ENQs.
Record locks within RLS are owned by a named UOW within a named CICS region. The lock owner name is the APPLID of the CICS region, plus the UOW id. For example, when CICS makes a request that may create a lock, CICS passes to VSAM the UOW id. This enables VSAM to build the lock name using the UOW id, the record key, and the name of the CICS region.
CICS releases all locks on completion of a UOW using a VSAM interface.
When more than one request requires an exclusive lock against the same resource, VSAM queues the second and subsequent requests until the resource is freed and the lock can be granted. However, VSAM does not queue requests for resources locked by a retained lock (see Active and retained states for locks).
VSAM supports two types of lock for files accessed in RLS mode:
Exclusive locks can be active or retained; shared locks can only be active (see Active and retained states for locks). Note that there are no delete locks in RLS mode.
Exclusive locks protect updates to file resources, both recoverable and non-recoverable. They can be owned by only one transaction at a time. Any transaction that requires an exclusive lock must wait if another task currently owns an exclusive lock or a shared lock against the requested resource.
Shared locks support read integrity (see Read integrity (in RLS mode)). They ensure that a record is not in the process of being updated during a read-only request. Shared locks can also be used to prevent updates of a record between the time that a record is read and the next syncpoint.
A shared lock on a resource can be owned by several tasks at the same time. However, although several tasks can own shared locks, there are some circumstances in which tasks can be forced to wait for a lock:
Shared locks for repeatable read requests, for recoverable and non-recoverable data sets, are held until the next syncpoint.
Exclusive locks against records in a non-recoverable data set remain held only for the duration of the request--that is, they are acquired at the start of a request and released on completion of it. For example, a lock acquired by a WRITE request is released when the WRITE request is completed, and a lock acquired by a READ UPDATE request is released as soon as the following REWRITE or DELETE request is completed. Exceptionally, locks acquired by sequential requests may persist beyond the completion of the immediate operation. Sequential requests are WRITE commands that specify the MASSINSERT option and browse for update requests. A lock acquired by a WRITE command with the MASSINSERT option is always released by the time the corresponding UNLOCK command completes, but may have been released by an earlier request in the WRITE MASSINSERT sequence. The exact request in the sequence that causes the lock to be released is not predictable. Similarly, a lock acquired by a READNEXT UPDATE command may still exist after the following DELETE or REWRITE command completes. Although this lock is guaranteed to be released by the time the subsequent ENDBR command completes, it may be released by some intermediate request in the browse sequence.
If a request is made to update a recoverable data set, the associated exclusive lock must remain held until the next syncpoint. This ensures that the resource remains protected until a decision is made to commit or back out the request. If CICS fails, VSAM continues to hold the lock until CICS is restarted.
Task 1 Task 2
CICS: READ(filea) UPDATE KEY(99)
VSAM: grants exclusive lock - key 99
CICS: READ(filea) KEY(99)
with integrity
VSAM: Queues request for shared lock
CICS: REWRITE(filea) KEY(99)
VSAM: holds exclusive lock until syncpoint
CICS: task completes and takes syncpoint
VSAM: frees exclusive lock
VSAM grants shared lock to task 2
VSAM RLS supports active and retained states for locks. The difference between these two types of lock is that whereas a request for a resource that has an active lock is queued until the resource becomes available, a request for a resource that has a retained lock fails immediately.
The active state is applicable to both exclusive and shared locks. However, only exclusive locks against recoverable resources can have their state changed from active to retained. The important characteristic of these states is that they determine whether or not a task must wait for a lock:
When a lock is first acquired, it is an active lock. It is then either released, the duration of the lock depending on the type of lock, or if an event occurs which causes a UOW to fail temporarily and which would therefore cause the lock to be held for an abnormally long time, it is converted into a retained lock. The types of event that can cause a lock to become retained are:
If a UOW fails, VSAM continues to hold the exclusive record locks that were owned by the failed UOW for recoverable data sets. To avoid new requests being made to wait for locks owned by the failed UOW, VSAM converts the active locks owned by the failed UOW into retained locks. Retaining locks ensures that data integrity for the locked records is maintained until the UOW is completed.
Exclusive recoverable locks are also converted into retained locks in the event of a CICS failure, to ensure data integrity is maintained until CICS is restarted and performs recovery.
Exclusive recoverable locks are also converted into retained locks if the VSAM data-sharing server (SMSVSAM) fails (the conversion is carried out by the other servers in the Sysplex, or by the first server to restart if all servers have failed). This means that a UOW does not itself have to fail in order to hold retained RLS locks.
Any shared locks owned by a failed CICS region are discarded, and therefore an active shared lock can never become retained. Similarly, active exclusive non-recoverable locks are discarded. Only locks that are both exclusive and apply to recoverable resources are eligible to become retained.
[[ Contents Previous Page | Next Page Index ]]