VMS Path Specifications include three basic elements:
All of these elements are always in upper case and
are not case sensitive or case preserving.
Example:
O.K. Let's take those in reverse order...
This portion of the VMS Path Specification is the most complex. Like DOS and unlike UN*X, it has a structure. Each element of the structure is significant.
The "Filename" and ".Extension" portions can each contain up to 39 characters. However, only one "dot" (".", a period) can appear in this portion of the VMS Path Specification in ODS-2. You'll see why later. ODS-5 provides for more flexible file naming to allow better interaction with UN*X and other systems where strict file naming syntax requirements are not imposed.
The ".Extension" portion is significant, like in DOS. When you run a program or invoke a command, the "image activator" looks for files with a ".EXE" extension by default. (A default value is one that is used when you do not specify a value explicitly.) When you invoke a command procedure (using the "@" operator), DCL looks for a file with a .COM extension by default.
The "Filename" and ".Extension" portions can contain characters from "A" to "Z", "0" to "9", "$" (a dollar sign), "_" (an underscore), or "-" (a dash or hyphen). No other "special" characters are allowed in ODS-2. ODS-5 provides for lower-case and mixed case in filenames and extensions, as well as multiple "dots" (periods). Avoid the "$" (dollar sign) and "-" (hyphen) characters for ISO-9660 compatibility.
The ";Version" portion represents a version number which can range from 1 to 32767 (the maximum positive value that can be expressed in a signed word integer). This concept is foreign to both DOS and UN*X. Note that on UN*X you can include, for example, ";1" at the end of a filename, as in "/usr/mydir/myfile.txt;1". However, the ";1" portion of a filename is meaningless to UN*X itself or the shell, although the semi-colon (";") can have a special meaning within some shell command expressions, such as to delimit multiple commands to be executed in a subshell in a pipeline.
On OpenVMS, the first version of a file has the version number ";1". Each subsequent version receives a higher version number. When files are listed, or when "searching" for files (F$SEARCH() in DCL, or LIB$FIND_FILE in a program), files are located in alphabetically by name and extension, and descending order by their version number.
The Directory portion of a VMS Path Specification indicates the path through the directory structure to a file. This is the only portion of a VMS Path Specification which can contain multiple "dots" (".", periods) on an ODS-2 volume. The dots are used to delimit directories in the path, in much the same way as UN*X uses slashes and DOS uses back-slashes. The entire expression is enclosed in square brackets ("[]").
Like DOS or UNIX, a directory is a special kind of file. Although it always has an extension of .DIR (unlike DOS or UN*X), there is a special flag which indicates that the file is a directory (like DOS or UN*X). This "attribute" of the file is only visible using DUMP/HEADER or DIRECTORY/FULL.
The Device portion of a VMS Path Specification can be the most deceiving. It can be a physical device name, a "logical name" which equates to a physical device name, a "logical name" which equates to a physical (or logical!) device name plus the entire path (a "non-rooted" logical name), or a "logical name" which equates to a physical device name plus a portion of a path (a "rooted" logical name).
By contrast, DOS uses only a single letter (a "drive letter"). The concept is foreign to UN*X because the whole of the available disk storage is viewed in UN*X as a single resource, regardless of how many physical devices that may include.
The VMS device name also has a structure. The expression "ddcu" is often used in examples to represent the device name. In "ddcu:": the "dd" portion indicates the device type (two(2) letters); the "c" portion indicates the controller number relative to first controller for that device type in the system (one(1) letter, "A" thru "Z"); the "u" portion indicates the unit number of the device on the controller (one(1) to four(4) digits, "0" thru "9999", up to five(5) digits, 0-99999 in more current versions of OpenVMS).
Examples of Device Types:
Examples of Device Names:
Allocation Class
The "Allocation Class" is a value that is used to logically separate
devices into user-defined classes. The allocation class of a device is expressed
as part of the device name.
Allocation class can also be used to resolve ambiguities. For example, if more
than one node in a cluster has a local SCSI disk called DKA0, node allocation
class or port allocation class can be used to resolve the ambiguity. This prevents
device names from being duplicated within a cluster. Thus, a device on any node
in a cluster can be accessed from another node in the same cluster, even if the
local node has a device by the same name.
When the allocation class for a device is zero(0), it is shown in various displays
(SHOW DEVICE, others) as "node$ddcu:", where "node" is the
node name of the device or system to which that device is directly attached.
Example: SATURN$DKA100:. Host-Based Volume Shadowing (HBVS) virtual devices are an
exception to this rule as DSA devices are always shown without a host node name or
an allocation class.
When the allocation class for a device is non-zero(0), it is shown in various displays
(SHOW DEVICE, others) as "$alloclass$ddcu:". Example: $35$DKA200:
Note that the Allocation Class of fibre channel disk devices is always one(1)
($1$DGAnnnnn:), and the Allocation Class of fibre channel tape devices is always
two(2) ($2$MGAnnnn:).
Logical Names - Non-Rooted
Logical names can be used to represent a device name and the complete path to a file.
Example:
$ SHOW LOGICAL SYS$LOGIN "SYS$LOGIN" = "DKA0:[MYDIR]"
Non-rooted logical names can include rooted logical names in their translations.
Logical Names - Rooted
Logical names can also be used to represent a device name and a portion of the path to a file.
Example:
$ SH LOG SYS$MANAGER "SYS$MANAGER" = "SYS$SYSROOT:[SYSMGR]" (LNM$SYSTEM_TABLE) $ SH LOG SYS$SYSROOT "SYS$SYSROOT" = "DKA0:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "DKA0:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
Rooted logical names must be DEFINEd (or ASSIGNed) using either physical device names or executive (or higher) mode logical names. You may actually see SYS$SYSROOT and SYS$COMMON translated like so:
$ SH LOG SYS$SYSROOT "SYS$SYSROOT" = "SYS$SYSDEVICE:[SYS0.]" (LNM$SYSTEM_TABLE) = "SYS$COMMON:" 1 "SYS$COMMON" = "SYS$SYSDEVICE:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)
Home Page Operating Systems Products Specialties Freeware
OpenVMS Page Bulletin Board Contact Us About Us
Tradenames, trademarks, service marks, etc. appearing on this page are the property of their registered owners.
"DJE Systems" is a service mark of David J. Dachtera, doing business
as DJE Systems.
This page Copyright ©1998,1999 by David J. Dachtera, All Rights
Reserved.