The previous column (Part 1) examined the basics of the OpenVMS logical name facility. This installment focusses on how applications use and misuse logical names.
Logical names are used implicitly via Record Management Services (RMS); or explicitly via the $TRNLNM system service and associated run time library routines. Logical names can appear almost anyplace that a filename can appear; thus logical names potentially affect the opening of every file on an OpenVMS system. Iterative translation can be combined with differing user contexts to greatly leverage the logical name facility.
Logical names provide great leverage, but like most leverage, can be mis-used, leading to poor performance and wasted resources. While today's systems often have greater resources than yesterday's, workloads are often correspondingly higher, supporting larger numbers of users with more complex and numerous tasks.
Once, at a client site, I was asked to look at a "login performance" problem. What I found was several inter-related problems, some of which I will write about in later columns. However, the "login performance" was rather straightforward, and it also gave rise to an inefficient logical name structure.
The first problem was that each user, when logging in, executed a common procedure which defined upwards of 40 logical names. Virtually every user created the exact same logical names, bit for bit. In this particular case, the involved users covered several different UIC groups, and the particular application was the primary use of the system (if the user community had been more diverse, I would have designed a slightly more sophisticated solution, with the same effect, but not imposing the overhead of more logical names on each user).
Thus, each user's login command file referenced a common command file which contained a multitude of
$ ASSIGN string logical-name
commands, each one for a different logical name used by the application. A lexical function was used in some cases to generate the component of the logical name equivalence string which referred to the directory path.
The first step could have been creating Group logical name tables (created and populated at system startup), however, the nature of the definitions permitted a different approach.
I first modified the common procedure so that the names would be placed in the System logical name table, and invoked the command file at system startup; thus eliminating the need for the names to be defined for each user at the time of login. This noticeably shortened the time required to login. However, we were not finished. In actuality, not all of the groups were using the exact same logical names. Some groups were using parallel logical name structures, as shown below (one name used as an example without sacrificing generality):
Taking advantage of iterative translation, we were able to normalize all
groups to use the common logical name:
Groups A, B, C||DATABASE||DATADISK:[DATA]DATABASE.FIL|
with different definitions for DATADISK contained in each Group logical name table.
Thus, the multitude of translations actually depended on the particulars of the value of the DATADISK logical name contained in the Group logical name table. Thus when using the directory command, the results illustrate the efects of the iterative translations:
||Actual File Name|
|for Group A
|for Group B
|for Group C
For a single logical name (DATABASE), the results are purely semantic. The payoff is the elimination of the duplicative names on a per-user basis, and the resulting conversion to a per incarnation of the application basis. As the late Senator Dirksen is reported to have said, “A million here, a million there,
sooner or later it is real money”.
If you have been counting, there are now a single copy of the application specific logical names, plus a single logical name in each Group logical name table to identify the particular directory tree, a substantial savings in memory space, login overhead, spawn overhead, and complexity.
This is actually one of the simpler uses of the logical name facility. In our next installment, we will look at a more complex example.
Next article in this series by Robert Gezelter:
Logical Names (Part 3) >>
Previous article in this series by Robert Gezelter:
<< Logical Names (Part 1)
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 email@example.com.