Documentation - Record Locks

When are record locks set?

A record lock is set when a data record is read from an internal file if the file is open for SHRU sharing mode and OUTIN access.

When are record locks released?

An existing record lock will be released by any of the following operations:

• REWRITE
• WRITE
• READ
• RELEASE
• CLOSE

What record locks are eligible to be released?

The original defined behavior of record locks dealt with multiple instances of an open file as being all part of the same group.  That is, even if a particular file is open on more than one file number there is a maximum of ONE record lock set by each instance of LBASIC.  Therefore any of the above operations that set or release a record lock will do so independent of which file number actually holds the lock.

This will continue to be the default behavior of record locks in LBASIC and SBW.

An enhancement was provided in 1999 to change this behavior in order to take advantage of maintaining a persistent lock on a file record while allowing the manipulation of other sections of the same file.  This is of particular use when used in conjunction with the ability to CHAINSUB to a child program and subsequently return to the current execution flow with data, file pointers, and now record locks undisturbed by the child program's processing.

In order to turn on this new behavior the function Machine$("RECORD-LOCKMODE=n") was created.  The original (and default) record lock behavior is named mode 0 (zero) and the new behaviors are named mode 1 (one) and mode 2 (two).

Mode one and two behavior can be described simply by stating that the CHAINSUB child program can not manipulate any record locks set by the parent program unless the CHAINSUB is executed with the FILES parameter to share the actual file opens.

Thus, we now have the possibility that the child program can be blocked by a record lock set by the parent program.  Mode one behavior explicitly prevents this from happening by permitting the child program to read and modify the record locked by the parent program.

Mode two behavior will result in a record lock trap on any IO statement that is blocked by the record lock of the parent program.  In this event if the IO statement does not have a LOCKED trap active the child program will go into a permanent record lock wait condition (deadlock).

Details of RECORD-LOCKMODE=0 Behavior

The following table describes the behavior of record locks in mode 0 and assumes that the file is open SHRU and OUTIN on all relevant file numbers.  Note that in mode 0 it is irrelevant which CHAINSUB level initiated the record lock.

Details of RECORD-LOCKMODE=1 Behavior

The following table describes the behavior of record locks in mode 1 and assumes that the file is open SHRU and OUTIN on all relevant file numbers.  Any operations dealing with locks in the same CHAINSUB level are treated according to the mode 0 table above.

Details of RECORD-LOCKMODE=2 Behavior

The following table describes the behavior of record locks in mode 2 and assumes that the file is open SHRU and OUTIN on all relevant file numbers.  Any operations dealing with locks in the same CHAINSUB level are treated according to the mode 0 table above.

Send mail to mailto:rja@superb.cyberportal.net with questions or comments about this web site.
Last modified: October 28, 1999