There are fundamental differences in how file and record locking are implemented on OpenVMS and Unix/Linux systems. These differences can affect applications that rely on OpenVMS-style locking.

File locking

On OpenVMS, when a file is opened in exclusive mode (SHARE:0), the lock is enforced at the operating system level through RMS. The operating system prevents any other program from opening the file. Locking is mandatory and enforced globally, regardless of what program attempts access.

On Unix/Linux, file locking is implemented using POSIX advisory locking via fcntl(). Advisory locks are cooperative. If a file is opened with SHARE:0,

1. Other Synergy programs recognize and respect these locks and will receive a "File in use" error.
2. Non-Synergy processes (e.g., shell commands like cat, custom applications, and FTP utilities) will not see or honor the lock.

This behavior is a characteristic of the POSIX file-locking model, not a limitation of the Synergy runtime. This applies to all Synergy locks on Linux, including file locks, record locks, and ISAM tree locks.

Record locking

There is also a fundamental difference in record-locking behavior:

1. On OpenVMS, record locks are per-channel (RMS-managed). A record locked on one channel is seen as locked on another channel within the same process.
2. On Unix/Linux, record locks are per process, not per file descriptor. A record locked on one channel does not block access from another channel within the same process. Locks only block other processes.

Code written with OpenVMS-style assumptions (where the second channel would be blocked by a lock held on the first channel) may encounter unexpected behavior on Unix/Linux, including scenarios such as "Deleted record" errors if one channel deletes a record that another channel is working with.

See Record locking on Unix for more details about this behavior.

Controlling intraprocess file-locking behavior

The INTRAFILELOCKS environment variable affects file locking behavior within the same process. For example, for the following code,

open(ch1=0, u:i, "testfile.ism")

open(ch2=0, u:i, "testfile.ism", SHARE:0)

1. If INTRAFILELOCKS=1 (the default), the second open generates a "File in use by another user" error. This behavior matches Windows and OpenVMS expectations.
2. If INTRAFILELOCKS=0, no error is generated, because the runtime’s intraprocess file lock enforcement is disabled and Unix advisory locks do not block within the same process. This setting is provided only for backward compatibility with version 8.1.7 and earlier applications that violate file-sharing rules. We do not recommend setting INTRAFILELOCKS to 0.

Achieving true exclusive access on Unix/Linux

When all file access is performed by Synergy programs, advisory locking works reliably: all Synergy processes use the same fcntl-based locking and respect each other’s locks. The challenge arises in mixed workflows where both Synergy and non-Synergy processes (e.g., FTP utilities, shell scripts, or third-party applications) access the same files. Because POSIX locks are advisory, non-Synergy processes will not see or honor locks placed by the Synergy runtime, and there is no runtime option that forces mandatory system-level locking equivalent to OpenVMS. Here are some possible workarounds:

1. Use temporary filenames (recommended).

Have external processes (e.g., FTP) write to a temporary file using a naming convention that your Synergy program recognizes and ignores (e.g., some.txt.tmp). When the write is complete, rename it to the final filename (e.g., some.txt). The Synergy program should be written to only process files with the final filename, ignoring files with the temporary naming convention.

On Linux, rename() is an atomic operation on the same file system. The file appears under its new name instantaneously, so the Synergy program will never see a partially written file under the final filename.

1. Check whether another process has the file open before processing it.

Within your Synergy program, use the lsof command to determine whether another process has the file open. If lsof indicates the file is in use, skip it and try again later.

1. Temporarily remove file permissions and then restore them.

For example,

proc

   xcall spawn("chmod 000 testfile.txt")

   Console.WriteLine("Locked testfile.txt")

   Console.WriteLine("Press ENTER to unlock the file")

   Console.ReadLine()

   xcall spawn("chmod 644 testfile.txt")

Note that this does not affect processes that already have the file open, and there is a race condition between permission changes and other processes opening the file.

Each of these approaches has benefits and drawbacks depending on the application design and environment.

Summary

1. OpenVMS uses mandatory, OS-enforced locking through RMS.
2. Unix/Linux uses POSIX advisory locking via fcntl().
3. On Unix/Linux, locks are cooperative and per process.
4. Record locks held on one channel do not block another channel within the same process.
5. INTRAFILELOCKS can help align behavior more closely with OpenVMS.
6. There is no single runtime option on Unix/Linux that provides mandatory system-wide locking.

Understanding these distinctions is critical when porting applications between OpenVMS and Unix/Linux or when diagnosing locking-related issues.