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).

The Master File Directory

At the top level of an ODS filesystem is the master file directory (MFD), which contains all top-level directory files (including itself), and several system files used to store filesystem information. On ODS-1 volumes, a two-level directory structure is used: each user identification code (UIC) has an associated user file directory (UFD), of the form [GROUP.USER]. On ODS-2 and later volumes, the layout of directories under the MFD is free-form, subject to a limit on the nesting of directories (8 levels on ODS-2 and unlimited on ODS-5). On multi-volume sets, the MFD is always stored on the first volume, and contains the subdirectories of all volumes.

The following system files are present in the ODS MFD:

• INDEXF.SYS;1—Index file
• BITMAP.SYS;1—Storage bitmap file
• BADBLK.SYS;1—Bad block file
• 000000.DIR;1—The MFD directory file itself
• CORIMG.SYS;1—Core image file
• VOLSET.SYS;1—Volume set list file (ODS-2/5 only)
• CONTIN.SYS;1—Continuation file (ODS-2/5 only)
• BACKUP.SYS;1—Backup log file (ODS-2/5 only)
• BADLOG.SYS;1—Pending bad block (ODS-2/5 only)
• SECURITY.SYS;1—Volume security profile (ODS-2/5 only)
• QUOTA.SYS;1—Quota file (optional and available under ODS-2/5 only)
• GPT.SYS;1—GUID Partitioning Table (GPT) (OpenVMS I64 EFI boot structures, optional on OpenVMS Alpha)

Note that the filesystem implementation itself does not refer to these files by name, but by their file IDs, which always have the same values. Thus, INDEXF.SYS is always the file with NUM = 1 and SEQ = 1.

Index file: INDEXF.SYS

The index file contains the most basic information about a Files-11 volume set. Block 1 is the boot block, which contains the location of the primary bootstrap image, used to load the VMS operating system. This is nearly always located at physical block 0 on the disk, so that the hardware firmware can read it. This block is present even on non-system (non-bootable) volumes.

After the boot block is the home block. This contains the volume name, the location of the extents comprising the remainder of the index file, the volume owner's UIC, and the volume protection information. There are normally several copies of the home block, to allow recovery of the volume if it is lost or damaged.

The rest of the index file is composed of file headers, which describe the extents allocated to the files residing on the volume, and file metadata such as the owner UIC, ACLs and protection information. Each file is described by one or more file headers—more than one can be required when a file has a large number of extents. The file header is a fixed-length block, but contains both fixed– and variable–length sections:

• The header contains the NUM and SEQ, the protection (security) information, and the location(s) of the rest of the file header.
• The ident section contains the accounting metadata: the filename, creation and modification times, and the time of the last backup.
• The map describes which physical disk blocks (extents) map to each virtual block of the file.
• The access control list contains the ACL information for the file.
• The reserved area is space at the end of the file header which is not used by the operating system. This can be used by for customer- or vendor-specific information.
• The last two bytes of the header are a checksum of the previous 255 words, to verify the validity of the header.

If possible, the map and ACL sections of the header are contained completely in the primary header. However, if the ACL is too long, or the file contains too many extents, there will not be enough space in the primary header to store them. In this case, an extension header is allocated to store the overflow information.

The file header begins with 4 offsets (IDOFFSET, MPOFFSET, ACOFFSET and ROFFSET). Since the size of the areas after the fixed-length header may vary (such as the map and ACL areas), the offsets are required to locate these additional areas. Each offset is the number of 16-bit words from the beginning of the file header to the beginning of that area.

If the file requires multiple headers, the extension segment number (SEGNUM) contains the sequence number of this header, beginning at 0 in the first entry in INDEXF.SYS.

STRUCLEV contains the current structure level (in the high byte) and version (in the low byte) of the filesystem; ODS-2 being structure level 2. An increase in the version number indicates a backwards-compatible change that older software may ignore; changes in the structure level itself are incompatible.

W_FID (containing three values: FID_NUM, FID_SEQ and FID_RVN, corresponding to the file, sequence, and relative volume number) contains the ID of this file; EXT_FID (again composed of three values) holds the location of the next extension header, if any. In both of these values, the RVN is specified as 0 to represent the "current" volume (0 is not normally a valid RVN).

FILECHAR contains several flags which affect how the file is handled or organised:

• NOBACKUP causes this file to be ignored when a backup is run.
• WRITEBACK enables cached (delayed) writes to the file.
• READCHECK causes all reads of the file to be done twice, and compared to ensure data integrity.
• WRITCHECK results in all writes being verified by a subsequent read and compare.
• CONTIGB causes the OS to attempt to allocate storage for the file in as contiguous a manner as possible.
• LOCKED is set if the file is deaccess-locked. If set, this indicates that the file was not properly closed after its last use, and the contents may be inconsistent.
• CONTIG indicates that the file is stored contiguously on disk; that is, each virtual block i is mapped to the logical (physical) block i + k, for some constant k.
• BADACL is set if the file has an invalid access control list.
• SPOOL is set if the file is a spool file, such as an intermediate file used during printing.
• DIRECTORY is set if the file is a directory.
• BADBLOCK is set if the file contains bad blocks.
• MARKDEL is set if the file has been marked for deletion, but is still in use; it will be deleted once closed by the last user.
• NOCHARGE, if set, causes space used by the file to not be taken from the owner's storage quota.
• ERASE causes the file's contents to be overwritten when it is deleted.

ACCMODE describes the privilege level at which a process must be running in order to access the file. VMS defines four privilege levels: user, supervisor, exec, and kernel. Each type of access - read, write, execute and delete - is encoded as a 2-bit integer.

FILEPROT contains the discretionary access control information for the file. It is divided into 4 groups of 4 bits each: system, owner, group and world. Bit 0 corresponds to read access, 1 to write, 2 to execute and 3 to delete. Setting a bit denies a particular access to a group; clearing it allows it.

If the file header is an extension header, BACKLINK contains the file ID of the primary header; otherwise, it contains the file ID of the directory file containing the primary entry for the file.

Other files

• Storage bitmap file: BITMAP.SYS

The bitmap file is responsible for storing information regarding used and available space on a volume. It contains the storage control block (SCB), which includes summary information detailing ???, and the bitmap, an array of bits to indicate if a cluster of blocks on the disk is free or allocated. In early versions of VMS the cluster comprised 3 blocks but as disk sizes have increased, so has the cluster size.

• Bad block file: BADBLK.SYS

The bad block file contains a list of bad block on the physical volume, so that the system can avoid allocating them to files. This file was used more in the early days when disks were typically manufactured with more bad patches on the surface.

• Volume set list file: VOLSET.SYS

The volume set list is located on volume 1 of a volume set, and contains a list of labels of all volumes in the set, and the set's volume name.

• Continuation file: CONTIN.SYS

When a file on a multi-volume set crosses the boundary of two constituent volumes, the continuation file is used as its extension header and describes the volume where the rest of the file can be found.

• Quota file: QUOTA.SYS

The quota file contains information of each UIC's disk space usage on a volume. It contains a record for each UIC with space allocated to it on a volume, along with information on how much space is being used by that UIC. NOTE: The DISK QUOTA feature is optional and the file will only exist if the feature was ever enabled.

• Volume security profile: SECURITY.SYS

The volume security profile contains the volume's owner UIC, the volume protection mask, and its access control list.

• GUID Partitioning Table: GPT.SYS

This file overlays and protects the MBR (Master Boot Record) and GPT (GUID Partitioning Table) disk structures utilized for and by the Extensible Firmware Interface console bootstrap. This file is created by default during OpenVMS I64 disk initialization, and is optionally created (with INITIALIZE/GPT) on OpenVMS Alpha.