HP 3000 Manuals

Ap D. Multiple Calls to DBLOCK [ TurboIMAGE/XL Database Management System Reference Manual ] MPE/iX 5.0 Documentation


TurboIMAGE/XL Database Management System Reference Manual

Appendix 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.

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.

If it is absolutely necessary to make multiple DBLOCK calls, the
following information about how TurboIMAGE/XL performs locking may be
useful.



MPE/iX 5.0 Documentation