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

124 Chapter4
Using the Database
Using the Locking Facility
4. DBPUT a new data entry in SUP-MASTER data set.
5. DBPUT a new data entry in INVENTORY data set for STOCK# = 4444A33B.
6. DBEND.
7. DBUNLOCK.
The locking in the above example was done around the entire transaction to maintain data
consistency during the multistep transaction.
Interactively Modify a Customer Account Order
1. DBLOCK SALES: ACCOUNT = 89393899.
2. DBFIND the CUSTOMER master data set entry with ACCOUNT = 89393899 in order to
prepare to read the chain of SALES data entries with the same ACCOUNT value.
3. DBGET each entry in the chain and display it to the user until the correct order is
located.
4. DBUPDATE the contents of the data entry according to the user's request.
5. DBUNLOCK.
In this interactive example, all data entries for ACCOUNT 89393899 in the SALES data
set are locked. Note that these locks are held while a dialog takes place with the terminal
operator; therefore, the lock could be held for several minutes. For this type of transaction,
it may be best to first perform a conditional lock to determine if the records are accessible.
For example, when a mode 6 DBLOCK is called with lock descriptor SALES: ACCOUNT =
89393899 and the lock does not succeed, a message similar to the one below can be
displayed by the program:
RECORDS BEING MODIFIED. WANT TO WAIT?
If the response is NO, then proceed with other processing. If the answer is YES, call
DBLOCK again with mode 5.
Issuing Multiple Calls to DBLOCK
In order to guarantee that two processes cannot deadlock, TurboIMAGE/XL does not allow
two DBLOCK calls to be made without a DBUNLOCK between the DBLOCK calls. Two exceptions
to this rule are stated here:
• A redundant call can be made to lock the whole database with DBLOCK mode 1 or 2
provided the call relates to the same access path. The redundant call will have no effect.
(This is allowed in order to maintain compatibility with earlier versions of IMAGE.)
• More than one DBLOCK call can be made if the program from which multiple DBLOCK
calls are issued has the MPE/iX Multiple RIN (MR) capability.
The DBLOCK procedure is similar to the MPE/iX FLOCK procedure in that DBLOCK can put a
process into a waiting state and thus can cause a deadlock to occur. For example, a
deadlock can occur if process A is waiting for an MPE/iX file to be freed by process B, and
process B is waiting for a database entity to be unlocked by process A. Therefore, issuing a
DBLOCK in conjunction with a lock applied by an MPE/iX intrinsic, such as FLOCK,orbythe
COBOLLOCK procedure requires MR capability. The use of MR capability is not