Document revision date: 30 March 2001 | |
Previous | Contents | Index |
If the open-by-name-block option is specified (FAB$V_NAM), RMS examines the name (NAM or NAML) block for a valid device identification field (NAM$T_DVI or NAML$T_DVI), directory identification field (NAM$W_DID or NAML$W_DID), and file identification field (NAM$W_FID or NAML$W_FID). If these fields are present, RMS uses them to locate the file; all other components are ignored because they are not needed. If the open-by-name block succeeds, no expanded or resultant string is produced.
If these fields are not present in the name block or if an open-by-name block is not specified (for example, an Open service not preceded by a Parse service), RMS performs the translation and application of defaults. A file can also be created using the name block device and directory identification fields, but RMS does not use the file identification.
If an open-by-name block is requested for remote DECnet for OpenVMS
file access between two OpenVMS systems, RMS does not check the device
identification, directory identification, or file identification to
determine whether the requested open-by-name block operation can be
performed. Instead, RMS checks to see if a qualified resultant string
is present. If a qualified resultant string is not present, RMS
translates logical names and applies defaults as if an open-by-name
block operation was not requested (see Section 6.2.2).
6.2.2 File Specification Formats and Translating Logical Names
To form the file specification, RMS examines and attempts to translate each program-supplied file specification, beginning with the primary file specification string indicated by the contents of the FAB$L_FNA and FAB$B_FNS fields, or by the contents of the NAML$L_LONG_FILENAME and NAML$L_LONG_FILENAME_SIZE fields.
A file specification may have one of three formats:
node::"foreign-filespec" node::"task-spec-string" |
RMS attempts to translate the node name so that it can determine
whether a logical node name is present. Only a logical or physical node
name (including an access control string, if present) is allowed if the
translation is successful. If a logical node name is found, the
translation is repeated. When translation cannot be performed, the file
specification is copied directly into the expanded string. The quoted
string is not parsed except to determine if it refers to a file or a
task on the remote system. For additional information about these
formats, see the DECnet for OpenVMS Networking Manual.
node::device:[root.][directory]filename.type;version |
Note that in the context of a file specification, brackets do not imply
optional components. The only optional components are the node
component and the root component.
RMS isolates the components,
checks them for proper syntax, and copies them to the expanded string.
If a node name is present, RMS attempts to translate it as a logical
node name as described previously. If a name in the device component is
present and the node name is omitted, RMS attempts to translate the
device name as a logical name.
After translating a logical name,
RMS determines whether the translation contains a duplicate component.
If RMS finds a duplicate component in the primary file specification
translation, it signals an error. Conversely, if RMS finds a duplicated
component in the default string file specification translation or in
the related string file specification translation, it ignores
(discards) the duplicate component.
If the node name is omitted and
the device component does not translate successfully, RMS treats the
name in the device component as a device name.
If the logical name
translates successfully, RMS makes several checks and then performs the
appropriate task:
The logical name translation procedure reveals two conventions. First,
if the file specification has been parsed previously by an RMS file
service, it uses the open-by-name-block option to save processing time.
Second, a logical device name must be placed at the beginning of a file
specification, unless it is preceded by a node name that indicates the
node where the logical name should be translated.
6.2.3 Special Parsing Conventions
Additional parsing conventions for advanced file specifications include
search lists, related file specifications, and the way RMS handles
directory specifications.
6.2.3.1 Parsing Conventions for a Search List
RMS uses several conventions when processing a search list logical name.
Invalid device name (RMS$_DEV)
Device not ready or not mounted (RMS$_DNR)
Directory not found (RMS$_DNF)
File not found (RMS$_FNF)
Privilege violation (RMS$_PRV)
$ DEFINE X DISK1:[RED],DISK2:[WHITE] $ DEFINE Y X,DISK1:[BLUE] |
$ DEFINE PRIM DISK1,DISK2 $ DEFINE DEF [BIG],[BEST] |
PRIM:FILE |
Finally, the program must provide the default specification that includes the search list (DEF) for the directory together with the file type component:
DEF:.DAT |
Given this information, RMS looks for FILE.DAT using the file specification data in the following order:
Primary File Specification |
Default File Specification |
Expanded String |
---|---|---|
DISK1 | [BIG] | DISK1:[BIG]TEST.DAT; |
DISK2 | [BIG] | DISK2:[BIG]TEST.DAT; |
DISK1 | [BEST] | DISK1:[BEST]TEST.DAT; |
DISK2 | [BEST] | DISK2:[BEST]TEST.DAT; |
This section describes the special processing needed to implement sticky defaults when a search list is used in a related file specification for an input file parse. The term sticky default means that file specification components from the first file specification are applied as defaults to the next file specification component, eliminating the need, for instance, to specify the device specification for each file specification when all the files are located on the same device.
The related file specification provides defaults when a related file name block is present. To use the related file specification, the file access block must specify the address of the primary file's name block (in the FAB$L_NAM or FAB$L_NAML field), and that name block must specify the address of the related file's name block (in the NAM$L_RLF or NAML$L_RLF field). The related file's name block must specify the address of a valid file specification in the resultant string (NAM$L_RSA/NAM$B_RSS or NAML$L_LONG_RESULT/NAML$L_LONG_RESULT_ALLOC) field. Typically, an RMS file service (other than Parse) places the file specification in the resultant string.
You can specify whether the related file is used as an input file specification or an output file specification by setting (output file specification parsing) or resetting (input file specification parsing) the output-file parse (FAB$V_OFP) bit in the file-processing options (FAB$L_FOP) field .
When an input file specification is being parsed, you can have multiple related name blocks by specifying the second related file's name block address in the NAM$L_RLF or NAML$L_RLF field of the first related name block, the address of the third related name block in the NAM$L_RLF or NAML$L_RLF field of the second name block, and so forth. The use of multiple related name blocks is especially useful for search lists; one related name block might contain a file type that can be used by any file specification in a search list, another might contain the full file specification that was produced by the first search list file specification, and another might contain the full file specification produced by the second search list file specification. This method allows the file specifications in a search list to provide sticky defaults, a characteristic associated with DCL command lines that contain multiple file specifications.
For a search list to be applied as a related file specification, the related file specification must not be a resultant string but must include the search list logical name. The related file specification in this case must describe the original primary file specification. For example, consider the following search list definition:
$ DEFINE WORK DISK1:[MINE],DISK2:[GROUP] |
To process lists of input files---such as WORK:A,B,C,---your program
must supply the string WORK:A as the related file specification, not
DISK2:[GROUP]A.DAT. The routines LIB$FIND_FILE and LIB$FILE_SCAN are
provided to perform this special processing; consult the OpenVMS RTL Library (LIB$) Manual
for additional information; also refer to Example 5-2, which shows
how to call the LIB$FIND_FILE routine.
6.2.3.3 Input File Specification Parsing
When the output-file parsing bit (FAB$V_OFP) is reset and the node name is omitted, RMS processes the related file specification as an input file specification. This is shown in the following table. Note that the only wildcard character allowed is a single asterisk.
File Specification Component |
Null Field Specification |
Wildcard (*) Field Specification |
---|---|---|
Node | Use related file specification | Illegal |
Device | Use related file specification | Illegal |
Directory | Use related file specification | Remains wild |
Filename | Use related file specification | Remains wild |
Type | Use related file specification | Remains wild |
Version | Remains null | Remains wild |
When the FAB$V_OFP bit is reset and a node name is present, RMS processes the related file specification as an input file specification, as shown in the following table:
File Specification Component |
Null Field Specification |
Wildcard (*) Field Specification |
---|---|---|
Device | Remains null | Illegal |
Directory | Remains null | Remains wild |
Filename | Use related file specification | Remains wild |
Type | Use related file specification | Remains wild |
Version | Remains null | Remains wild |
When the FAB$V_OFP bit is set and a node name is not present, RMS processes the related file specification as an output file specification, as shown in the following table:
File Specification Component |
Null Field Specification |
Wildcard (*) Field Specification |
---|---|---|
Node | Remains null | Illegal |
Device | Remains null | Illegal |
Directory | Remains null |
Substitute from related file
specification with restrictions |
Filename |
Use related file
specification |
Substitute from related
file specification |
Type |
Use related file
specification |
Substitute from related
file specification |
Version | Remains null |
Substitute from related
file specification |
When the FAB$V_OFP bit is set and a node name is present, RMS processes the related file specification as an output file specification, as shown in the following table:
File Specification Component |
Null Field Specification |
Wildcard (*) Field Specification |
---|---|---|
Device | Remains null | Illegal |
Directory | Remains null |
Substitute from related file
specification with restrictions |
Filename |
Use related file
specification |
Substitute from related
file specification |
Type |
Use related file
specification |
Substitute from related
file specification |
Version | Remains null |
Substitute from related
file specification |
As shown in the previous table, a wildcard character in an output directory specification is subject to the following syntax restrictions:
[*...] |
RMS processes wildcard characters in an output directory specification as follows:
One of the components of a file specification is the directory specification. RMS supports two conventions or types of directory specifications, one of which is used more often than the other.
When RMS applies defaults to a directory specification in a file specification, the rules differ depending on what type of a directory specification is present. Two directory syntax conventions are available to access directories: normal and rooted. The default directory access is normal syntax. That is, you can specify the directory desired using the directory syntax described in the OpenVMS DCL Dictionary.
Previous | Next | Contents | Index |
privacy and legal statement | ||
4506PRO_017.HTML |