Record locking for indexed and relative files is used for all machines. Currently, record locking is not supported for sequential files. Only files opened in the I/O mode will actually lock records; input-only files will not lock records they read. Record locking occurs in one of two modes: automatic (the default) and manual. In automatic mode, a record is locked when it is read (unless the WITH NO LOCK or ALLOWING UPDATES phrase of the READ statement is used). In manual mode, records are locked only when WITH LOCK is specified on the read statement. Both modes support single and multiple record locks. When single record locks are used (the default), the currently locked record is released whenever any I/O statement is executed for the file. When multiple record locks are used, records become unlocked only when an UNLOCK or CLOSE statement is executed for the file (or a COMMIT is executed for a transaction file).
It is possible to get a record locked condition when you are doing a READ, REWRITE, or DELETE on a file.
On most machines, a READ performed without locking will not get a record-locked condition even if another process has the record locked. This allows report programs to run without hindrance. Note, however, that on some older UNIX machines, non-locking READs will receive the record-locked condition if another process has the record locked. This is because on these machines, UNIX enforces the record locks. Most UNIX systems do not enforce record locks (the current system V standard does not allow for it) so this should not continue to be a problem for long. PC-based environments (i.e., LANs, Windows) also enforce record locks, introducing a portability issue. For unenforced locks in a PC-based environment, you should use indexed files rather than relative files.
runcbl behaves in one of two fashions when a locked record is encountered. Normally, the return is immediate and the file status variable is set to the locked condition. When this happens, the I/O fails. Unlike most errors, the current record pointer is not changed by a locked condition. This allows multiple READ NEXTs to be performed in a loop until the lock condition disappears, without losing track of the current record position.
In RM/COBOL compatibility mode, however, this rule changes if the file does not have a Declarative associated with it. In this case, locked records on REWRITE and DELETE statements are handled as described above. On READ statements, however, runcbl automatically waits until the record becomes unlocked. This is identical to the behavior of RM/COBOL version 2. The programmer should beware when using this technique, however. Deadlocks can occur if two programs end up waiting for each other to unlock a desired record. For this reason, we recommend against using this technique.
When ROLLBACK is enabled in a file's FILE-CONTROL entry, record and file locking rules are extended for that file. Every record updated as part of a transaction is locked until that transaction is committed or rolled back. The COMMIT and ROLLBACK verbs remove these locks. For more information see Extended Locking Rules.