There is one additional set of qualifiers on the ASSIGN command which are often used, and we will encounter when constructing examples. These parameters affect the mode of the logical name created/redefined by the $CRELNM system service used by the implementation of the ASSIGN command.

The relevant qualifiers are /EXECUTIVE_MODE, /SUPERVISOR_MODE, and /USER_MODE. The /EXECUTIVE_MODE qualifier requires the privilege to get to executive mode (CMEXEC) or the higher privilege required to enter kernel mode (CMKRNL). When first examining this aspect of OpenVMS, many users question why it is necessary to implement this mechanism at all. The answer is "system integrity".

On some level, virtually all images executing on an OpenVMS system use logical names. The integrity problem comes when a program executing at a higher privilege level needs access to certain facilities, which are pointed to by a logical name. If a privileged program were to use a logical name defineable by a user for critical purposes, it would be possible to spoof operations, compromising system integrity as surely as entering kernel mode itself. For this reason, programs are able to restrict their logical name translations to names which were defined in executive mode, which can only be defined by a user or image running with the CMEXEC privilege enabled.

/SUPERVISOR_MODE is the default mode for logical names created with the ASSIGN command. SUPERVISOR_MODE logical names in the JOB and PROCESS logical name tables persist for the duration of the process or job respectively (or until they are deleted using the DEASSIGN command). Of course, it is possible to create/delete logical names directly using OpenVMS system services or run-time library routines. However, these system services and run-time library routines require the use of a programming language, and most users, managers, (and for that matter, programmers) will use the DCL commands the majority of the time.

The /USER_MODE qualifier presents an option which is not well understood by many users. USER_MODE logical names are automatically deleted when an image exits. Thus, there are no cleanup operations required. No matter how many USER_MODE logical names are created prior to the execution of an image, they will all be deleted from the logical name table when the image exits. the auto-DEASSIGN feature of USER_MODE logical names only applies to the PROCESS logical name table, however.

Of course, there are other qualifiers on the ASSIGN command, and other facets of the logical name facilities including cluster-wide logical names, group-wide logical name tables, private logical name tables, name table quotas, rooted logical names, search lists, to name a few. Each facet of the logical name table facilities has its uses, and we will cover other facets in future columns.

For now, we have accumulated enough qualifiers and keywords to construct useful examples of how logical names can be used effectively, ranging from individual development environments to global system management.

The OpenVMS Consultant welcomes questions from readers about OpenVMS and related technologies. Please submit your questions to theOpenVMS Consultant.

Next article in this series by Robert Gezelter:
Logical Names (Part 5) >>

Previous articles in this series by Robert Gezelter:
<< Logical Names (Part 3)
<< Logical Names (Part 2)
<< Logical Names (Part 1)

Biography:

Robert Gezelter is the Founding Principal of the consulting firm that bears his name (www.rlgsc.com).

The firm's consulting practice emphasizes in-depth technical expertise in computer architectures, operating systems, networks, security, APIs, and related matters. Mr. Gezelter has worked with OpenVMS since the initial release of VAX/VMS in 1978.

His clients include small businesses to the Fortune 10, locally, nationally, and internationally on matters spanning the range from individual telephone questions to major projects.

He can be reached at gezelter@rlgsc.com.