|February 15, 1995 No. 80|
Improved NPL SHARE Locking Option
The MS-DOS, MS-Windows and 386 DOS/Extender versions of NPL Release 4.10.23.00.x now support Byte 39 of $OPTIONS (previously supported only under the UNIX revisions of NPL). This option can improve performance on both local drives (using SHARE lock calls) and network drives on Novell NetWare or NetBIOS based networks.
NOTE: Developers can expect performance a increase in all environments by enabling this option.
When the HEX (01) bit of $OPTIONS in byte 39 is set to 0 (the default value), NPL issues an implied $OPEN for the duration of each disk statement, if an explicit $OPEN has not already been issued. The purpose of this implied $OPEN is to ensure that if any other users have issued an explicit $OPEN against the diskimage, the explicit lock is respected and the platter is not accessed until the lock is released.
When the HEX (01) bit of $OPTIONS byte 39 is set to 1, NPL will allow atomic disk statements (i.e., those completed with a single read or write operation) to access a diskimage file without issuing an implied $OPEN. If other users have issued an explicit $OPEN against the diskimage, the platter is not accessed until the lock is released.
The following disk statements are always atomic:
- DATA LOAD BA
- DATA SAVE BA
- DATA LOAD BM *
- DATA SAVE BM *
- LIMITS INDEX
* If size of buffer is an even multiple of 256 bytes
NOTE: The net effect of this option is to improve overall concurrent access to shared diskimage files (especially in networked environments where filelocking is typically slow; i.e., NetBIOS type networks), if the majority of access to these diskimage files use the above operations.
Under MS-DOS, MS-Windows and 386/DOS Extender, a request to read or write from a file that is currently locked returns an error. If this occurs in any situation where the current task has suppressed an implied lock, NPL assumes the error could be due to a lock on the data being held by another user or task. NPL then issues the suppressed implied lock and then retries the operation. If an error still occurs, the error is reported (as on previous releases), otherwise, no error is reported and the program continues.
NOTE: The size of an implied lock in the event of a retry is affected by the HEX (02) bit of $OPTIONS byte 39. If the HEX (02) bit is 0 (the default), a full file lock is issued. When the HEX (02) bit is set to 1, only the area being read by the statement is locked.
For maximum concurrence both the HEX (01) and HEX (02) bits should be set to 1.
Under UNIX, if an explicit $OPEN is active on a file, any requests to read or write data in the file automatically wait to be released.
The following describes all possible values of $OPTIONS byte 39. Values in this byte are treated as bit flags controlling special optimizations for implied $OPEN operations.
|Bit Mask||Bit Value|
|HEX(01)||0||Default. No special avoidance of implied $OPENs.|
|1||The RunTime suppresses implied $OPENS on atomic DATALOAD/DATASAVE BA/BM operations. Under UNIX NPL waits for the lock to be released. Under MS-DOS, MS-Windows and 386/DOS-Extender, NPL receives an error and issues a retry. If an error is still encountered, it is reported as in previous releases.|
|HEX(02)||0||Default. No special handling of implied $OPENs.|
|1||The RunTime issues limited file locks instead of implied OPENs for atomic DATALOAD/DATASAVE BA/BM operations. On UNIX systems with both the HEX (01) and HEX (02) bits set, the HEX (01) bit takes precedence.|
|HEX(04)||0||Default. No special handling of implied $OPENs.|
|1||The RunTime issues limited file locks instead of implied $OPENs for atomic DATALOAD/DATASAVE DC/DA operations.|
|All other bits||0||Reserved. Default to 0 and should not be used.|
NOTE: Previous MS-DOS based releases of NPL will treat all values the same as HEX (00) on all MS-DOS based operating systems. The HEX (01) bit of $OPTIONS byte 39 was previously implemented only on UNIX based operating environments.
Use of the HEX (04) bit can also substantially increase the ability to access a diskimage concurrently by many users, provided the accessed areas do not overlap. This option should only be set if DATALOAD DC/DA operations are always used by the application to access single data records (saved with one DATASAVE statement), starting at the first sector of the record.
WARNING: If the HEX (04) bit is set, reading multiple consecutive records with a single DATALOAD DC/DA statement without first locking the entire diskimage (with $OPEN) can cause access failures on some operating systems, notably in MS-DOS based environments (i.e., NetBIOS, Novell etc...) The errors may be reported as a RunTime error or as a "Device not ready" screen.
Since this failure can only occur in multi-user environments when records other than the first in a block are concurrently accessed (and locked) by another user, this problem may not appear when testing the application in a single user environment.