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