In BS2000 the length of a PAM file is always an integral multiple of a PAM block, regardless of its content. In BS2000 OSD/BC V10.0 and higher, the catalog entry for PAM files contains the entry Last Byte Pointer (LBP), in which the real length of the file in bytes can be stored. As a result, especially files which are stored on a network server (NAS) can also be read and written by all systems which access them (also UNIX) in a manner which is precise to the byte.
This functionality may also be available in BS2000/OSD as of V8.0.
Previously the length of a PAM file was determined with the help of an auxiliary construction by identifying the actual end of the file with a marker. This auxiliary construction can be dispensed if LBP is used.
All C runtime functions which open PAM files are affected by this interface.
The fopen(), fopen64(), freopen(), freopen64(), open(), open64()creat(), creat64() functions have consequently been extended with the lbp switch. Details can be found in the descriptions of the relevant functions.
When existing files are opened or read, these functions behave as follows independently of the lbp switch:
If the file's LBP is not equal to 0, it is evaluated. Any marker which is present is ignored.
When LBP = 0, a marker is searched for, and the file length is determined from this. If no marker is found, the end of the last complete block is regarded as the end of file.
When files are closed which have been modified or newly created, the behavior depends on the lbp switch when the file is opened or on the environment variable LAST_BYTE_POINTER.
Environment variable LAST_BYTE_POINTER
The purpose of the environment variable LAST_BYTE_POINTER is to enable existing programs to use the LBP without any need to intervene in them. Permanently linked programs then only need to be relinked with the current CRTE. For programs linked with PARTIAL-BIND or CRTE-BASYS, it is sufficient if the current CRTE or CRTE-BASYS is installed.
If one of the functions affected is called without the lbp switch, its behavior depends on the environment variable LAST_BYTE_POINTER:
LAST_BYTE_POINTER=YES
The fopen(), fopen64 () and freopen(), freopen64() functions behave as if lbp=yes were specified in the mode parameter.
The open(), open64() and creat(), creat64() functions behave as if O_LBP were specified in the mode parameter.
When a file is opened, a check is made to see whether LBP support is possible. If this is not the case, the function concerned will fail and errno is set to ENOSYS.
When a file which has been modified or newly created is closed, no marker is written (even if one was present), and a valid LBP is set. In this way files with a marker can be converted to LBP without a marker.
In the case of NK files the last logical block is padded with binary zeros, in the case of K files the file is padded to the physical end of file.
LAST_BYTE_POINTER=NO
The fopen, fopen64 and freopen, freopen64 functions behave as if lbp=no were specified in the mode parameter.
The open(), open64() and creat(), creat64() functions behave as if O_NOLBP were specified in the mode parameter.
When a file which has been newly created is closed, the LBP is set to zero (=invalid). A marker is written. In the case of NK files the last logical block is padded with binary zeros, in the case of K files the file is padded to the physical end of file.
When a file which has been modified is closed, the LBP is set to zero (=invalid). A marker is written only if a marker existed before. If the file had a valid LBP when it was opened, no marker is written as in this case it is assumed that no marker exists.
In the case of NK files the last logical block is padded with binary zeros, in the case of K files the file is padded to the physical end of file.
If the environment variable is not set, the functions behave as if it had the value NO.
Details on using environment variables can be found in section “Environment variables”).