TurboIMAGE/XL Database Management System Reference Manual (30391-90012)

Appendix D 655
Multiple Calls to DBLOCK
D Multiple Calls to DBLOCK
For the purpose of deadlock prevention, the system views any call to DBLOCK in which
something is actually locked as a lock on a single resource, even though the call may have
specified multiple lock descriptors. Any program which does not have the Multiple RIN
(Resource Identification Number) capability (CAP=MR) can only have one resource locked
at a time, and thus can only call DBLOCK once without an intervening call to DBUNLOCK. It
may be necessary for some applications to violate this rule. The purpose of this appendix is
to tell you how to avoid problems that can arise if you prepare your application programs
with MR capability (CAP=MR).
Some typical situations in which CAP=MR could be required are the following:
• A program has two or more databases open and wishes to lock part or all of each
database simultaneously. (One or more of the databases may be on a remote HP 3000.)
• A program wishes to lock an MPE file and a database simultaneously.
• A program wishes to lock data entries in a database and, after reading their contents, to
apply further locks. This is very dangerous and is not recommended, because deadlocks
can occur very easily.
The danger in all cases is that a deadlock could occur. For example, suppose process A has
data set 1 locked and is trying to lock data set 9, and process B has data set 9 locked and is
waiting for data set 1. In this case, a deadlock has occurred and the only way to break it is
to restart the operating system.
To avoid restarting the operating system, use DBCONTROL mode 7 to activate deadlock
detection for all open databases. If a deadlock occurs, an error 26 is returned to the process
instead of causing a system hang. The process can subsequently call DBUNLOCK to release
all locks on the database placed by the access path.
TurboIMAGE/XL avoids deadlocks within single calls to DBLOCK by first sorting the lock
descriptors into an internally-defined sequence. It then applies the locks in ascending
order sorted by data set number, then by the value provided for the lock item. You can use
the same strategy in avoiding deadlocks. First define an order in which entities should be
locked and then impose a rule on all programmers that this order be adhered to. The
sequence of unlocking is not important. The rule that you establish should apply to all of
the following lockable entities:
• Databases, data sets, and data entries
• Remote databases, data sets, and data entries
• MPE files (FLOCK), global RINs (LOCKGLORIN), KSAM files (FLOCK), and files locked
with the COBOLLOCK procedure
When applying multiple DBLOCK calls to the same database, extreme caution should be
exercised because the deadlock situations can be very subtle. For example, if a process
locks a data set and then attempts to lock the database, the process will wait for itself
forever.