HP OpenVMS Systems Documentation
Guide to OpenVMS File Applications
6.4 DID-Abbreviated Directories (Alpha Only)
To support Extended File Specifications, RMS's user interface was extended to include capacities for the larger specifications that are sometimes necessary to access ODS-5-named files. (See the OpenVMS Record Management Services Reference Manual.) To take full advantage of all of the new features, applications would have to be updated to use the interface extensions. To provide extended capabilities (such as access to deep directories) to applications that continue to use the older interface, RMS supports the generation and acceptance of file specifications with an abbreviated form of root or directory specification, known as a DID (for Directory ID) abbreviation.
The DID is an alternate form of subdirectory specification that is not relative to the MFD. It takes the form (for ODS-2 and ODS-5 disks) of three decimal numbers separated by commas and can be used in the MFD position in a root or directory component specification.
Examples of valid root and directory components with DIDs are as follow:
A DID can also be used in place of a subdirectory in a root or directory component, but subdirectories located to its left in the specification (above it in the directory tree) are elided by RMS, as shown in the following example:
If a specification contains both a root with a DID and a directory with a DID, the root will be ignored (though not elided) by RMS.
The directory ID numbers are those that are displayed for a directory with the DIRECTORY/FILE_ID DCL command, as shown in the following:
When RMS attempts to generate a file specification that is too long for the application's output buffer, pointed to by the NAM block expanded or resultant string field, NAM$L_ESA or NAM$L_RSA; or by the NAML block short expanded or short resultant string file, NAML$L_ESA or NAML$L_RSA, it replaces the root and directory component with one that has the DID for the lowest level subdirectory of the replaced component(s). The specification that results can then be used as input to RMS.
It should be noted that not all RMS features are available with DIDs.
For example, attempts to use sticky defaulting with a root or directory
with a DID will result in an error. And you cannot create a directory
using a DID.
On Alpha systems, when a file specification, even with DID abbreviation, is too long to fit into a resultant name buffer (NAM block NAM$L_RSA field or NAML block NAML$L_RSA field), RMS attempts to generate a short-enough file specification by identifying the file with its file ID (three decimal numbers separated by commas, surrounded by brackets) in the file name component.
In cases in which the file type component would otherwise be presented, a generated file specification will either include the entire type or will not include any type (including the "." delimiter), depending upon whether or not there is space.
In cases in which the version component would otherwise be presented, a generated file specification will include the version component.
As a human-readable aid in recognizing files, when a FID is generated, the name component also contains a DCL-legal initial subset of the actual file name. The subset consists of the first 38 simple characters (where "^U1234" is six simple characters) of the actual file name, followed by "~".
No attempt is made to resolve ambiguities for files that differ only after the first 38 simple characters of their names.
An example of a generated name with a FID is as follows:
Such a file specification can be used as input to RMS, with some
A FID can be used for input to RMS, but only the FID is significant. The subset portion of the name component, the type component, and the version component are ignored by RMS.
As input, the FID-abbreviated file name component is not used as a default (as from a related file specification to replace a wildcard in an output specification). Instead, the output specification will get a null file name, as shown in the following:
Note that generated names with FIDs are possible only for resultant
specifications, which refer to specific files, and not for expanded
specifications, which do not necessarily refer to one file.
Process-permanent files are files that remain open independent of image activation and rundown. Process-permanent files are created by setting the process-permanent file bit (FAB$V_PPF) in the file-processing options field (FAB$L_FOP). When the bit is set, RMS-maintained internal data structures are allocated in the process control region of memory for the life of the process. Thus, process-permanent files can remain open across image activations. SYS$COMMAND, SYS$INPUT, SYS$OUTPUT, and SYS$ERROR are all opened in this manner by the LOGINOUT command image.
The DCL command OPEN also opens files in this manner. With user mode code, you can access process-permanent files only indirectly. RMS provides a subset of the total available operations to the indirect accessor.
Indirect accessors gain access to process-permanent files through the logical name mechanism, as follows:
|Function (Service)||FDL and RMS Options|
|Read records (Get)||ACCESS GET specified or FAB$B_FAC field FAB$V_GET set|
|Locate records (Find)||ACCESS GET specified or FAB$B_FAC field FAB$V_GET set|
|Delete records (Delete)||ACCESS DELETE specified or FAB$B_FAC field FAB$V_DEL set|
|Add new records (Put)||ACCESS PUT specified or FAB$B_FAC field FAB$V_PUT set|
|Truncate file (Truncate)||ACCESS TRUNCATE specified or FAB$B_FAC field FAB$V_TRN set|
|Modify records (Update)||ACCESS UPDATE specified or FAB$B_FAC field FAB$V_UPD set|
|Access blocks (see text)||ACCESS BLOCK_IO specified or FAB$B_FAC field FAB$V_BIO set; under certain conditions, ACCESS RECORD_IO or FAB$B_FAC FAB$V_BRO|
The record-access functions you request are compared with the protection on the specified file. If your process is limited to reading and locating records, it should have read access to the file. If your process is deleting, adding, truncating, or updating records, it must have write access to the file. RMS permits any process that may delete, add, truncate, or modify records to also locate and read records because write access to a file also implies read access.
You can perform block I/O operations using the Read, Space, and Write services. Block I/O is usually only used by applications written in VAX MACRO or other low-level languages. Note that when ACCESS BLOCK_IO is specified, the application program must also specify either SHARING USER_INTERLOCK or SHARING PROHIBIT.
Different types of record operations can be specified to define the type of access to be allowed for other processes, as shown in Table 7-2.
|Function (Service)||FDL and RMS Options|
|Read records (Get)||SHARING GET specified or FAB$B_SHR field FAB$V_SHRGET set|
|Locate records (Find)||SHARING GET specified or FAB$B_SHR field FAB$V_SHRGET set|
|Delete records (Delete)||SHARING DELETE specified or FAB$B_SHR field FAB$V_SHRDEL set|
|Add new records (Put)||SHARING PUT specified or FAB$B_SHR field FAB$V_SHRPUT set|
|Modify records (Update)||SHARING UPDATE specified or FAB$B_FAC field FAB$V_SHRUPD set|
|No access||SHARING PROHIBIT or FAB$B_SHR field FAB$V_NIL set|
|User interlocking||SHARING USER_INTERLOCK or FAB$B_SHR field FAB$V_UPI set|
|Multistreaming||SHARING MULTISTREAM or FAB$B_SHR field FAB$V_MSE set|
If other processes are limited to reading and locating records, they are unable to modify or add records, and record-lock checking is not performed. If other processes are allowed to delete, add, or modify records, they can also read records; however, record-lock checking occurs. All record-access functions use interlocked interprocess file sharing.
No access denies access to all accessors except the accessor who specifies the option. This option might be used when a file is shared infrequently or when doing a major update. When you use this option, be sure to close the file promptly when other users are trying to access the file. Choose this option or the user-interlocking option when using block access. To use the Queue I/O Request system service, specify the FILE USER_FILE_OPEN attribute (FAB$L_FOP field FAB$V_UFO set). The no-access option does not allow file sharing and requires that your process have write file protection access.
User interlocking permits the user to maintain interlocking protection (including maintaining the end-of-file mark). For any other form of file sharing, RMS controls the reading and writing of I/O buffers to ensure the integrity of file and record structures. This option is useful for nonshared sequential files and for block I/O access using RMS or the Queue I/O Request system service.
Multistreaming allows your process to access the same file using more than one record stream and allows other users to access the file using interlocked interprocess file sharing (unless SHARING PROHIBIT is also specified). When you select this option, select the appropriate SHARING record operations, such as SHARING GET. When multiple streams are connected, the buffers allocated for each stream become part of a buffer cache for the entire process. (A buffer cache is a common shared buffer pool intended to minimize I/O.) A record operation on one stream may use cached buffers from a previous record operation on a different stream that referenced the same buckets.
When you open or create a file, you must specify the file access and file sharing you want for it. When using FDL or RMS, the default is to read records from the file (ACCESS GET) and to allow others accessors to read records from the file (SHARING GET). Typically, an application program may want to read records (ACCESS GET) while allowing other accessors to add records (SHARING PUT). You might want to modify records (ACCESS UPDATE) while allowing other accessors to add new records to the file (SHARING PUT).
When you create a file, the default is for FDL and RMS to add records to the file (ACCESS PUT) and to not allow others to access the file (SHARING NONE). When you create a file with the create-if option, it is especially important to specify the access and sharing values. In this instance, you have denied yourself access if the file already exists because you have specified SHARING NONE and you are not the initial accessor. One way to avoid this when you create a file is to allow most operations for other users (such as SHARING GET, SHARING PUT, SHARING UPDATE, and SHARING DELETE).
Combinations of file access and file sharing that specify a mixture of interlocked interprocess file access and user-interlocked interprocess file sharing allow the application program to access the file without record locking protection. Such combinations are not recommended for general use; they should be used only for application programs that require read-only access to a file. Other combinations may cause an error, such as requesting ACCESS BLOCK_IO without specifying SHARING NONE or SHARING USER_INTERLOCK.