With optimistic locking support for z/TPFDF, applications can open subfiles without a hold (lock) and then subsequently decide to hold the subfile. Prior to this support, you could lock a subfile only when the subfile was first opened. This gave the applications two main choices for locking:
- Lock a subfile if there was a possibility it would be updated. This pessimistic approach to locking meant that locks might be unnecessarily obtained even if no updates were ultimately needed.
- Open a subfile without a lock, but once it has been determined that an update is needed, close and re-open the subfile and potentially re-read several records. This approach would potentially result in additional, unnecessary processing and I/O.
Optimistic locking support for z/TPFDF allows you to make updates to subfiles while minimizing the lock hold time by only holding the lock for the specific update. With this support, you can lock an already opened subfile, even if it was opened without a lock. If the file is using sequence update counters, z/TPFDF might be able to maintain all core blocks and retained LREC pointers associated with the subfile so that they can be used during subsequent processing, depending on the circumstances. You also can release a lock for an already opened subfile, even if it was opened with a lock. When you release a lock for a locked subfile, you can choose whether to discard all pending modifications.
The best candidates to use optimistic locking are applications that:
- Access databases that use sequence update counters
- Have a low chance of update collisions.
Two new pairs of APIs are introduced:
- DBHOLD/dfhold, which hold (obtain a lock on) an already opened subfile
- DBUHLD/dfuhld, which unhold (release a lock for) an already opened subfile, either committing the changes and keeping the data in memory, or discarding changes.
For more information, see the APEDIT for APAR PI20336.