Files-11 is the file system used in the RSX-11, IAS, and OpenVMS operating systems from Digital Equipment Corporation. It supports record-oriented I/O, remote network access, and file versioning. The original ODS-1 layer is a flat file system; the ODS-2 version is a hierarchical file system, with support for access control lists.
Files-11 is similar to, but significantly more advanced than, the file systems used in previous Digital Equipment Corporation operating systems such as TOPS-20 and RSTS/E.
History The original ODS-1 version of Files-11 provided a rudimentary non-hierarchical directory structure, based on assigning one directory per user account. Each user account was represented by two numbers, a [project,programmer] pair, and had one associated directory; this was similar to the RSTS/E file system. Special system files, such as program executables and the OS itself, were stored in the directory of a reserved system account.
While this was suitable for PDP-11 systems, which possessed limited permanent storage capacity, VAX systems with much larger hard drives required a more flexible method of file storage, so the ODS-2 version of Files-11, introduced in VMS, provided a hierarchical directory layout in particular.
Overview "Files-11" is the general term for five separate file systems, known as on-disk structure (ODS) levels 1 through 5.
ODS-1 is the flat file system used by the RSX-11 OS, supported by older VMS systems for RSX compatibility, but never used to support VMS itself; it has been largely superseded by ODS-2 and ODS-5.
ODS-2 is the original VMS file system. Compared with ODS-1, it is a hierarchical file system.
Although seldom referred to by their ODS level designations, ODS-3 and ODS-4 are the Files-11 support for the CD-ROM ISO 9660 and High Sierra Format file systems, respectively.
ODS-5 is an extended version of ODS-2 available on Alpha, IA-64 and x86-64 platforms which adds support for case-preserving filenames with non-ASCII characters and improvements to the hierarchical directory support. It was originally intended for file serving to Microsoft Windows or other non-VMS systems as part of the "NT Affinity" project, but is also used on user disks and Internet servers.
Directory layout
All files and directories in a Files-11 file system are contained inside one or more parent directories, and eventually under the root directory, the master file directory (see below). The file system is therefore organised in a directed acyclic graph (DAG) structure.
In this example (see right), File 2 has a directory entry under both Dir 2 and Dir 3; it is "in" both directories simultaneously. Even if removed from one, it would still exist in the other directory until removed from there also. This is similar to the concept of hard links in UNIX, although care must be taken that the file is not actually deleted on disks that are not set up for hard links (only available on ODS-5 disks, and then only if the disk has hard links enabled).
Disk organization and naming An operational VMS system has access to one or more online disks, each of which contains a complete, independent file system. These are either local storage or, in the case of a cluster, storage shared with remote systems.
In an OpenVMS cluster configuration, non-private disks are shared between all nodes in the cluster (see figure 1). In this configuration, the two system disks are accessible to both nodes via the network, but the private disk is not shared: it is mounted for use only by a particular user or process on that machine. Access to files across a cluster is managed by the OpenVMS Distributed Lock Manager, an integral part of the file system.
Multiple disks can be combined to form a single large logical disk, or volume set. Disks can also be automatically replicated into shadow sets for data security or faster read performance.
A disk is identified by either its physical name or (more often) by a user-defined logical name. For example, the boot device (system disk) may have the physical name $3$DKA100, but it is generally referred to by the logical name SYS$SYSDEVICE.
File systems on each disk (with the exception of ODS-1) are hierarchical. A fully specified filename consists of a nodename, a username and password, a device name, directory, filename, file type, and a version number, in the format:
NODE"accountname password"::device:[directory.subdirectory]filename.type;ver
For example, [DIR1.DIR2.DIR3]FILE.EXT refers to the latest version of FILE.EXT, on the current default disk, in directory [DIR1.DIR2.DIR3].
DIR1 is a subdirectory of the master file directory (MFD), or root directory, and DIR2 is a subdirectory of DIR1. A disk's MFD is identified by [000000].
Most parts of the filename can be omitted, in which case they are taken from the current default file specification. The default file specification replaces the concept of "current directory" in other operating systems by providing a set of defaults for node, device name and directory. All processes have a default file specification which includes disk name and directory, and most VMS file system routines accept a default file specification which can also include the file type; the TYPE command, for example, defaults to ".LIS" as the file type, so the command TYPE F, with no extension, attempts to open the file F.LIS.
Every file has a version number, which defaults to 1 if no other versions of the same filename are present (otherwise one higher than the greatest version). Every time a file is saved, rather than overwriting the existing version, a new file with the same name but an incremented version number is created. Old versions can be deleted explicitly, with the DELETE or the PURGE command, or optionally, older versions of a file can be deleted automatically when the file's version limit is reached (set by SET FILE/VERSION_LIMIT). Old versions are thus not overwritten, but are kept on disk and may be retrieved at any time. The architectural limit on version numbers is 32767. The versioning behavior is easily overridden if it is unwanted. In particular, files which are directly updated, such as databases, do not create new versions unless explicitly programmed.
ODS-2 is limited to eight levels of subdirectories, and only uppercase, alphanumeric names (plus the underscore, dash, and dollar sign) up to 39.39 characters (39 for the filename and another 39 for the extension). ODS-5 expands the character set to lowercase letters and most other printable ASCII characters, as well as ISO Latin-1 and Unicode characters, increases the maximum filename length and allows unlimited levels of subdirectories. When constructing a pathname for an ODS-5 file which uses characters not allowed under ODS-2, a special "^" syntax is used to preserve backwards compatibility; the file "file.tar.gz;1" on an ODS-5 disk, for example, would be referred to as "file^.tar.gz"—the file's name is "file.tar", and the extension is ".gz".
File security: protection and ACLs Access control is based on User Identification Codes (UICs). A UIC includes a user number and a group number; the latter is also referred to as a project number. A logged-in user has a UIC, and a file is owned by a UIC.
RSX-11 and IAS
In RSX-11 and IAS, access control is governed by four groups of permissions:
System Owner Group World
And four permission bits: Read Write Extend Delete
The "system" access applies to any user whose UIC group number is less than or equal to octal 10, or decimal 8); "owner" and "group" apply to the owner of the file and that user's user group, and "world" applies to any other user.
VMS In VMS, the four permission bits are: Read Write Execute Delete
with Execute permission rather than Extend permission.
The "system" access applies to any user whose UIC group number is less than or equal to the system parameter MAXSYSGROUP (typically 8, or 10 octal). There is also a fifth permission bit, "Control", which is used to determine access to change file metadata such as protection. This group cannot be set explicitly; it is always set for System and Owner, and never for Group or World.
file security is also affected by four system privileges, which allow users holding them to override access controls: BYPASS: user implicitly has RWED access to all files, regardless of file protection; READALL: user implicitly has R access to all files; SYSPRV: user may access files based on System protection; GRPPRV: user may access files based on System protection if their UIC group matches the file's group.
VMS 4.0 added ACL-based access control. ACLs allow additional privileges to be assigned on a user– or group–specific basis; for example, a web server's UIC could be granted read access to all files in a particular directory. ACLs can be marked as inherited, where a directory file's ACL applies to all files underneath it. ACLs are modified using the EDIT/ACL command, and take the form of identifier/access pairs. For example, the ACL entry
(IDENTIFIER=HTTP$SERVER,ACCESS=READ+EXECUTE)
would allow the user HTTP$SERVER to read and execute the file.
Logical names A logical name is a system variable which may reference a disk, directory or file, or contain other program-specific information. For example, the logical SYS$SYSDEVICE contains the system's boot device. A logical name normally refers to a single directory or disk, e.g. SYS$LOGIN: which is the user's login (home) directory (or directories); these logicals cannot be used as true disk names—SYS$LOGIN:[DIR]FILE is not a valid file specification. However, concealed logical names, defined by DEFINE/TRANSLATION=CONCEALED, can be used in that way; these rooted directories are defined with a trailing "." on the directory specification, hence
$ DEFINE/TRANS=CONCEAL HOME DISK$USERS:[username.]
would allow HOME:[DIR]FILE to be used. More common are simple logicals which point to specific directories associated with some application software which may be located in on any disk or any directory. Hence logical ABC_EXE may point to a directory of executable programs for application ABC and ABC_TEMP may point to a directory of temporary files for that same application and this directory may be on the same disk and in the same directory tree as ABC_EXE or could be somewhere on another disk (and in a different directory tree).
In a manner similar to Unix, VMS defines several standard input and output channels which are accessed through the logical names SYS$INPUT, SYS$OUTPUT, SYS$ERROR and SYS$COMMAND.
Logical names do not have a close equivalent in POSIX operating systems. They resemble Unix environment variables, except they are expanded by the file system, instead of the command shell or application program. They must be defined before use, so it is common for many logical names to be defined in the system startup command file, as well as user login command files. In VMS, logical names may reference other logical names (up to a predefined nesting limit of 10), and may contain lists of names to search for an existing filename. Some frequently referenced logical names are: