Logical Names: Part 1

The is the first of an ongoing series of columns related to the technologies relating to OpenVMS, its platforms, and related layered products and applications.

This column is intended for the broad spectrum of OpenVMS users, the people who support them, and the people who manage them. I will emphasize the technological issues, and leave discussions relating to sales, marketing, and related areas to others.

Please feel free to send questions and comments to me at <gezelter@rlgsc.com >.

OpenVMS is, somewhat unique among operating systems for the operational flexibility it offers. It is not unusual for even systems managers to go for years without needing to pay attention to which physical drive an application is using. One of these distinguishing features is the Logical Name facility, a vital, yet often under-appreciated guarantor of flexibility.

Logical names are pervasive in the OpenVMS environment. Relatively early in the startup process (aspects of which will appear in a future column), the system-wide logical name is initialized with a number of system-wide logical names. The usage of SYS$SYSROOT is instructive.

SYS$SYSROOT is virtually the only place where the actual system device is referenced by name (SYS$SYSDEVICE, SYS$COMMON, SYS$DISK, and SYS$SPECIFIC also reference the physical name; for those who love detail, SYS$SYSDEVICE and SYS$TOPSYS are actually combined to produce all of the other names during execution of the startup sequence).

The elegance of the approach is in its simplicity. Almost without exception, references are actually based on SYS$SYSROOT. Changes in the operating environment (e.g. different disks, or separate directory trees) only affect the value of SYS$SYSROOT (and its progenitors). This, combined with a uniform API for mass storage devices, makes the actual device configuration of the system virtually transparent to most of the system and applications. For example, SYS$HELP is defined as SYS$SYSROOT:[SYSHLP].

All of the logical names referenced so far are in the System Logical Name table. Most processes are associated with at least four logical name tables (Process, Job, Group, and System). Names are generally translated by first searching in hierarchical sequence the Process, Job, Group and System tables. Advanced users can control the search and translation process. Additionally, some translations preclude logical names defined by the end-users, for security and integrity reasons.

In the next installment, I will examine how these capabilities can be used to advantage in user applications.

URLs for referencing this entry

Long:	http://www.rlgsc.com/blog/openvms-consultant/logical-names-part1.html
Short:	http://rlgsc.com/r/20020924.html