Originally, I intended to devote this installment to a more detailed discussion of a typical, everyday use of logical names. In developing the example, I realized that we need first review some of the options on the ASSIGN command (the syntax of the DEFINE command is similar, although the operands are reversed); most people prefer one or the other for admittedly ideosyncratic reasons. Going through the different qualifiers and their effects will occupy more than a single column, so we will defer the example (which uses multiple qualifiers) by two columns, to Part 5.

There are several qualifiers that are commonly used on the ASSIGN command, and they have substantial impact on the ways in which logical names are displayed, translated, and used.

In Part 2, of this series, we explored an example where we took advantage of iterative translation to utilize a common set of logical names as a base to point to different files contained in different directory trees. The iterative translation process can be finely controlled; for example it can be stopped at a particular point, when it encounters a logical name whose defining ASSIGN command included the /TRANSLATION_ATTRIBUTES=TERMINAL option.

At this point, I should also mention that logical names whose values begin with an "_" are treated by the I/O services as physical device names, and do not undergo furthertranslation.

In addition to the TERMINAL option, the /TRANSLATION_ATTRIBUTES qualifier can include the CONCEALED option. The CONCEALED option will control whether the translated name will be displayed to the user when, for example, theDIRECTORY command is used (to be sure, it is not a security measure, as the information can be easily obtained using the SHOW LOGICAL command, but it does eliminatedistracting clutter from displays).

The /NAME_ATTRIBUTES qualifier can also be used to control how the logical name is created and used one defined. The CONFINE prevents the copying of the logical name into the PROCESS logical name table of a spawned supprocess. Obviously, it does not apply to logical name tables that are not subject to copying when a subprocess is created, such as the SYSTEM, GROUP, and JOB logical name tables.

The NO_ALIAS option, guarantees that no identically named logical name exists at outer (less-privileged) access mode. Future attempts to define a less privileged logical name in the same table will generate an error. An already existing outer mode name in the same table will be deleted. These options may both be used on the same command, as in ASSIGN/NAME_ATTRIBUTES=(CONFINE,NO_ALIAS).

As noted in the first column, each process is generally associated with several logical name tables, the SYSTEM, GROUP, JOB, and PROCESS logical name tables. By default, the ASSIGN command operates on the PROCESS logical name table. If it is desired to affect the JOB logical name table (for example, the logical name is also to be used by a parent, child, or sibling process in the same job) it would be appropriate to use the /JOB qualifier to place the resulting logical name in the JOB logical name table.

The /SYSTEM qualifier will cause the logical name to be placed in the SYSTEM logical name table, and thus available to alll processes on the present node. The /SYSTEM qualifier is only valid if the process has the SYSNAM (and/or SYSPRV) privilege enabled.

The /GROUP qualifier operates in a manner similar to the /SYSTEM qualifier, but it places the logical name in the process' group logical name table, shared with all other processes which are running under the same UIC (User Identification Code) as the current process. Modifying the GROUP logical name table requires the GRPNAM (and/or GRPNAM) privilege.

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

Previous articles in this series by Robert Gezelter:
<< 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 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 have ranged from small businesses to the Fortune 10 locally, nationally, and internationally.

He can be reached at gezelter@rlgsc.com.