SYS$SYSROOT and similar logical names

From: Phillip Helbig---remove CLOTHES to reply (helbig_at_astro.multiCLOTHESvax.de)
Date: 04/30/05 

Date: Sat, 30 Apr 2005 09:24:22 +0000 (UTC)

This is the default setup:

$ dir sys$manager:systartup_vms.com

Directory SYS$SYSROOT:[SYSMGR]

SYSTARTUP_VMS.COM;2

Total of 1 file.

Directory SYS$COMMON:[SYSMGR]

SYSTARTUP_VMS.COM;202

Total of 1 file.

Grand total of 2 directories, 2 files.
$ sh log sys$sysroot
   "SYS$SYSROOT" = "DSA133:[SYS0.]" [concealed,terminal] (LNM$SYSTEM_TABLE)
        = "SYS$COMMON:"
1 "SYS$COMMON" = "DSA133:[SYS0.SYSCOMMON.]" [concealed,terminal] (LNM$SYSTEM_TABLE)

This raises a number of questions.

First, why is SYS$SYSROOT used in two contexts: as the logical name
itself, and as the alias for the concealed directory name
DSA133:[SYS0.]? In other words, as a logical name, SYS$SYSROOT points
to two directories, namely DSA133:[SYS0.] and DSA133:[SYS0.SYSCOMMON.].
However, with the DIRECTORY command, SYS$SYSROOT shows up as the name of
only the first directory, the second showing up as SYS$COMMON (which, of
course, is in turn defined as DSA133:[SYS0.SYSCOMMON.]).

It seems it would make much more sense to define SYS$SYSROOT as

   "SYS$SYSROOT" = "SYS$SPECIFIC:"
1 SYS$SPECIFIC = "DSA133:[SYS0.]" [concealed,terminal] (LNM$SYSTEM_TABLE)
        = "SYS$COMMON:"
1 "SYS$COMMON" = "DSA133:[SYS0.SYSCOMMON.]" [concealed,terminal] (LNM$SYSTEM_T

This would have several advantages. First, it would put SYS$SPECIFIC
and SYS$COMMON on the same footing. (Note that the SYS$SPECIFIC logical
is defined by default, but it is not used in the definition Of
SYS$SYSROOT.) Second, it would make clear that SYS$SYSROOT refers to
both SYS$SPECIFIC and SYS$COMMON, as now in the definition of the
logical SYS$SYSROOT (except that the translation of SYS$SPECIFIC, rather
than SYS$SPECIFIC, is used in that definition) and not create any
confusion with the DIRECTORY command by suggesting that it refers to
only the former.

Second question: Since SYS$SYSROOT is defined as a search list, why not
use VMS$COMMON:[000000.] rather than [SYS0.SYSCOMMON.] in the
definition? This would make it unnecessary to have [SYS0.SYSCOMMON.] be
an alias for VMS$COMMON:[000000.] in the first place. The only
advantage I can see in the current scheme is that one can do something
like $ DIR [SYS0...] and have it pick up the stuff in
VMS$COMMON:[000000...] via the alias.

(At first I thought that the search-list functionality might be needed
during system startup before the software (which might be somewhere in
the search list) is running, thus one would have to use
[SYS0.SYSCOMMON.] explicitly rather than using SYS$SYSROOT. However, in
that case one could just use VMS$COMMON:[000000.] explicitly.)

Third, it is probably not supported, but it would make sense to me to
add a third translation for SYS$SYSROOT, namely pointing to a directory
on a non-system disk shared by all members of a cluster, for example
containing common SYSUAF.DAT etc. This would allow one redefinition
(which could be done, for example, only if this directory is available)
rather than defining SYSUAF and all the other logicals explicitly.

Actually, one might want to have two such additional definitions, one
preceeding the standard two and one following them. Things like
SYSUAF.DAT could be in the first directory of the search list, so that
all machines (satellites or boot nodes) would use them no matter what.
In the fourth directory in the search list, one could have things which
are used only if there is no entry in a previous directory in the search
list, which would allow one to put stuff in SYS$COMMON on a particular
system disk so that it is used by all nodes booting from that system
disk, but not by those booting from other system disks (which would pick
it up from the fourth directory in the search list).

Relevant Pages

  • Re: SYS$SYSROOT and similar logical names
    ... whereas in the current scheme you get SYS$SYSROOT:SYSUAF.DAT, ... NEWSGROUP KNOW THE ANSWER TO THIS QUESTION! ... > rather than defining SYSUAF and all the other logicals explicitly. ... > system disk so that it is used by all nodes booting from that system ...
    (comp.os.vms)
  • Re: SYS$SYSROOT and similar logical names
    ... > rather than defining SYSUAF and all the other logicals explicitly. ... > system disk so that it is used by all nodes booting from that system ... If VMS was starting from scratch right now, ...
    (comp.os.vms)
  • Re: cluster-wide logicals and startup
    ... contains SYSUAF.DAT etc and the corresponding logicals should be defined ... The license database is not on the system disk. ... shadowing is apparently a special case with respect to licenses). ...
    (comp.os.vms)
  • Re: PRODUCT behaviour warning
    ... I'd done an image backup to a saveset to ... > also a version of this system disk. ... PRODUCT makes "interesting" use of the logicals pointing to ... seing the colon after a device name). ...
    (comp.os.vms)
  • Re: Backup/Copy tree with alias file
    ... >> What is the advantage to using ALIAS? ... > logicals defined as search lists, I've never understood why this is ... IIRC, going back to V2.n and RSX compatibility mode stuff, the system ...
    (comp.os.vms)