Record locking

Because Synergy programs function in multiuser environments, files opened in update mode are automatically subject to record-level locking controls. No record locking is performed when a file is opened in input mode.

When a record is retrieved from a file opened in update mode, the data record is locked to prevent access to the record by another channel. Synergy DBL provides two types of locking that can be used at the same time on a channel: automatic and manual. Automatic locking releases a lock before locking another record; only one automatic lock exists on a channel. Manual locking locks a record until it is explicitly unlocked; multiple records can be manually locked on the same channel.


On Windows and UNIX, manual record locking is available only for ISAM files. If you specify a manual lock on a relative (or other) file, an automatic lock will be applied.

OpenVMS allows manual locks on RMS ISAM and relative files.

The default record locking state is automatic locking. If you specify LOCK:Q_NO_LOCK on the OPEN statement to change the default record locking behavior, no record locking is performed. When locking, a record is locked on an update channel only after a successful READ, FIND (with LOCK), READS, or Select.MoveNext, and no error has been generated except $ERR_KEYNOT and $ERR_RECBIG. $ERR_KEYNOT is only generated without an explicit MATCH qualifier or with MATCH:Q_GEQ


All locking on UNIX is process-based, so be careful when accessing the same file on multiple update channels in the same process. See Record locking on UNIX for more information.

On Windows and UNIX, you cannot write to or delete an unlocked record. If you OPEN a file in update mode with the Q_NO_LOCK qualifier, you can use STORE to add new records, but if you attempt to update or delete an existing record using WRITE or DELETE, you’ll get a “No current record” error.

On a READ statement, you can override the default automatic record locking behavior by specifying the LOCK qualifier. For example, if a file is opened in update mode, you can use the LOCK:Q_NO_LOCK qualifier to read a record without locking it, instead of having to perform an UNLOCK after the record is automatically locked.


If you’re reading a record that could be locked and you don’t plan to immediately update or delete it (for example, you’re displaying the record for examination), we suggest that you either use the LOCK:Q_NO_LOCK qualifier or execute an UNLOCK statement to allow other users to access the record.

An automatic record lock is released when one of the following conditions occurs:

A manual record lock is released when one of the following conditions occur:

When using manual locking on a file with data compression or variable-length records, all record updates (using the WRITE statement) must also update the saved RFA for that record (using GETRFA on the WRITE statement) because the record can be physically moved, thereby changing its file position. Alternatively, you can add the STATIC_RFA file option, which guarantees an RFA that remains static. (We recommend the latter.)

On Windows and UNIX, to retrieve information about locked records, you can run the chklock utility. For more details, see chklock. Depending on which options you specify, chklock returns the following types of information:

Synergy DBL record-locking behavior may differ on your system. Refer to the Professional Series Portability Guide for information about record-locking behavior on your system.

Record locking on UNIX

Locks on UNIX are process-based; if the same program opens the same file on two different channels in update mode, one channel won’t be affected by the other’s locks. Also, if the same record is read by both channels, the record will be unlocked by one channel without the other channel being aware of it. This means the record can be overwritten even when another user now has a lock. For this reason, we recommend that when opening the same file on another channel, it be in input mode rather than both in update mode.

If a user opens a file on more than one channel, Synergy DBL defers the actual system closing of the file until it has been closed on all channels opened by that user. This feature is necessary to maintain locks set by the other open channels, because on UNIX the system close releases all locks in the file held by the process, even if some of those locks were applied to a different channel that remains open. When the file is closed on one of the channels but remains open on other channels, Synergy DBL “holds” the channel until the file has been closed on all of the channels. All known record locks on the channel being closed are still unlocked, and all locks held on other channels remain locked, so no adverse effects due to this behavior should occur.

If you’re migrating from Windows or OpenVMS to UNIX, be aware that record locks are no longer channel-based as they are on these systems.

Optimistic locking technique

Synergy DBL also makes it possible for you to take advantage of optimistic record locking. Optimistic locking is a technique that cuts down on lock contention by shortening the duration of record locks during update operations. An application using an optimistic locking model during transactions will have two types of I/O operations: a get operation and an update operation. The get operation either reads a record without a lock (LOCK:Q_NO_LOCK) or reads it with a lock and then immediately unlocks it. The update operation occurs at the end of the transaction, by rereading the same record with a lock and then immediately writing out the new record and unlocking it.

Determining whether or not the record was changed is a key requirement of optimistic locking. Using GRFAs is one way to fill that requirement. When you initially read the record, you should save the GRFA that is returned, so that subsequently when you reread the record in your update phase, it can be used to ensure the record has not changed. This is automatically done by the READ statement using the RFA qualifier with the saved GRFA. If another processes has modified the record, a “Record not same” error ($ERR_RECNOT) is generated, but the record is still retrieved (but not locked). By trapping the error, you can adjust your processing using both versions of the record to appropriately handle the condition. (See Record file addresses (RFAs), GETRFA, and RFA for more information about GRFAs.)