iX V6.5 (30391-90011)

Chapter 4 125

Using the Database

Using the Locking Facility

recommended unless absolutely necessary.

Users whose programs have MR capability and issue multiple DBLOCK calls are responsible

for deadlock prevention. This type of locking must be done very carefully. Recovery from a

deadlock requires a restart of the operating system. No matter how many descriptors are

listed in a single DBLOCK call, TurboIMAGE/XL guarantees that deadlocks will never occur

provided that no executing program that accesses the database has MR capability.

Programs that execute successfully using TurboIMAGE/XL locks in a single process

environment will not execute in a process-handling environment without MR (Multiple

RIN) capability. (Refer to appendix D for more information on the MR capability.)

Releasing Locks

The locks held by a process for a particular access path of a database are relinquished

when the process calls DBUNLOCK; they are automatically relinquished when the process

closes the database, terminates, aborts, or is aborted by an operator. Failure of a program

to release locks will result in other programs waiting indeﬁnitely for any conﬂicting locks.

These programs, while in a waiting state, cannot be aborted by the operating system. An

attempt to abort such a waiting process will result in the abort taking effect as soon as the

process obtains the lock for which it was waiting.

NOTE

Any program that executes a DBGET in mode 5 or 6 should lock the chain in

the detail data set. This prevents the execution of any DBPUTs or DBDELETEs

to the detail data set from modifying the current chain, thereby preventing a

status 18 (broken chain) error.