In a prior installment, I promised a slightly more sophisticated example using logical names. A straightforward, yet extraordinarily common situation presents a logical first example: DISK$USERS (or as I often encounter it, DISK$department, where department can be anything from ACCOUNTING to ZOOLOGY).

The goal is simple and straightforward: create a directory structure on the disk, with each department viewing their branch of the tree as a logically separate disk/directory structure. In days before virtual volume managers, this permitted system managers to migrate segments of the user community from one disk to another as workloads waxed and waned; matching backup schedules and scale to each department's budget and needs. Even with virtual volume management systems and Enterprise Storage Arrays, this technique allows users or teams of users to create their own environments without needing assistance from a system's managers.

As an example, we will work with a mythical two disk system named MIRAGE with two disks, DKA0: and DKA100:. We will ignore DKA0: (used as the system disk). However, we want to structure DKA100: (which is labeled MIRAGEUSER1) into several seemingly separate trees of directories. To make the example real, let's create departmental directory trees for ACCOUNTING, PAYROLL, and DATAENTRY. For our convenience, the base of our sub-tree will be owned by the department.

We begin with MIRAGEUSER1 already mounted with the /SYSTEM qualifier, so it is fully available to all users authorized to access files on the volume (we will examine security issues in a future column). We have also created the roots for our logical directories in the Master File Directory (directory [000000], also referred to as the "MFD") using the following commands (which are downloadable from OpenVMS.ORG):

$ CREATE/DIRECTORY DISK$MIRAGEUSER1:[ACCOUNTING]/OWNER=[ACCOUNTING] -      /PROTECTION=(SYSTEM:RWED,OWNER:RWED,GROUP:RE,WORLD)

$ CREATE/DIRECTORY DISK$MIRAGEUSER1:[PAYROLL]/OWNER=[PAYROLL] -      /PROTECTION=(SYSTEM:RWED,OWNER:RWED,GROUP:RE,WORLD)

$ CREATE/DIRECTORY DISK$MIRAGEUSER1:[DATAENTRY]/OWNER=[DATAENTRY] -      /PROTECTION=(SYSTEM:RWED,OWNER:RWED,GROUP:RE,WORLD)

Before creating the directories, create the RIGHTSLIST identifiers for the individual departments (remember Account names can be a maximum of eight characters in the UAF). Since the account names need be within the length limits set by OpenVMS, some artful abbreviation may be in order. If taking advantage of this opportunity to create a departmental umbrella account in the UAF, be mindful of the UAF imposed limits (not to mention the limits of any procedure used to access the UAF, such as SYS$EXAMPLES:ADDUSER.COM – which requires the account's default disk to exist in advance of running the procedure).

Once we have created the directories for the highest levels of the structure, we can address the user visible environment. All user access to the disk structure is (and must be) via logical names. The next step is the creation of a series of logical names for users to access the departmental sub-trees as if they were individual disks. Specifically, the logical names need to be created:

• in Executive mode using the /EXECUTIVE_MODE qualifier (so they can be used by elevated mode programs),
• in the System logical name table using the /SYSTEM qualifier (to ensure consistency between different groups and users), and
• with the /TRANSLATION_ATTRIBUTES=CONCEALED attribute to encourage users, programs and command procedures to be independent of the actual mapping of a directory to a particular disk volume.

$ ASSIGN/SYSTEM/EXECUTIVE_MODE/TRANSLATION_ATTRIBUTES=CONCEALED -      DISK$MIRAGEUSER1:[ACCOUNTING.] DISK$ACCOUNTING

$ ASSIGN/SYSTEM/EXECUTIVE_MODE/TRANSLATION_ATTRIBUTES=CONCEALED -      DISK$MIRAGEUSER1:[PAYROLL.] DISK$PAYROLL

$ ASSIGN/SYSTEM/EXECUTIVE_MODE/TRANSLATION_ATTRIBUTES=CONCEALED -      DISK$MIRAGEUSER1:[DATAENTRY.] DISK$DATAENTRY

Of course, the process issuing these commands needs to hold the SYSNAM and CMEXEC privileges.

The next question is when these commands should be executed. Generally, I suggest that users locate these commands adjacent to the commands that are used to actually mount the underlying disks. It is important to remember to check the mount status of the volume before actually creating the logical names. Also, it may be desireable to disable all (or some) logins if the volume(s) fail to mount correctly (the are several approaches to address this issue, each with slightly different advantages and disadvantages, some of which we will look at in the future).

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

Previous articles in this series by Robert Gezelter:
<< Logical Names (Part 4)
<< 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.