|
|
|
USupported on UNIX
|
|
File locking on UNIX is implemented using the same system resource as record locking. For this reason, each file open requires at least one lock (for conventional file locking), in addition to any record locks applied by a READ operation. An application that opens a large number of files could exceed the maximum number of system-wide locks and generate the following error: “Internal runtime failure: Record locking problem.”
In the event this occurs, we recommend that you increase your system kernel parameter that controls the maximum number of locks allowed (typically FLCKREC or LOCKS, depending on your operating system). The parameter should be set to at least
number of running Synergy applications * maximum open files per application * 2
As a temporary solution, you can set system option #33, which disables this conventional file locking. As a result, however, all file SHARE access is also disabled.
|
Any file access that would normally have generated a “File in use by another user” error will now be allowed to continue and potentially cause data loss. This includes OPEN(O:mode), COPY, SORT, DELET, RENAM, ISCLR, and ISAMC. |
On Oracle Solaris systems, file locking is handled differently. Synergy uses a Solaris-only locking facility that allows true (Windows- and VMS-style) file sharing. (This is always in effect and is not disabled by option #33.) In addition, however, the conventional file locking must also be performed to handle network file access (NFS) to non-Solaris machines or when pre-8.1 Synergy runtimes are used to access the same files, where the Solaris-only locking facility is not available. If neither of these situations can occur, we recommend using system option #33 to turn off the additional conventional file locking. This can have a dramatic impact on systems with a large number of concurrent Synergy users.
