problems with sys$manager directory - 7.3-2

[sandyt]

I hope you can help me fix my system disk. About a month ago we put in a raid card to supply mirroring on our system disk (we added two disks, raided them, and then did an image backup from the old non-mirrored system disk to the new mirrored one). We have been using the mirrored one ever since, and have since used the old system disk for other things. We had to make a few minor changes after the system came up due to the device name change, but basically it has worked fine ever since.

Today, I happened to make a small change in the sylogicals.com file, and then noticed something very strange with the files:
from system did dir sylogicals.com/size/date
and this is what I find:
Directory SYS$SYSROOT:[SYSMGR]

SYLOGICALS.COM;29 14 3-MAR-2010 12:16:46.00
SYLOGICALS.COM;28 14 15-FEB-2007 13:39:04.32
SYLOGICALS.COM;27 14 15-JAN-2008 12:31:58.97
SYLOGICALS.COM;26 14 17-FEB-2010 10:07:42.69
SYLOGICALS.COM;25 14 15-JAN-2008 12:31:58.97

Total of 5 files, 70 blocks.

Directory SYS$COMMON:[SYSMGR]

SYLOGICALS.COM;6 14 15-JAN-2008 12:31:58.97
SYLOGICALS.COM;5 14 15-FEB-2007 13:39:04.32

Total of 2 files, 28 blocks.

Grand total of 2 directories, 7 files, 98 blocks.

syst-t>sh log sys$manager

"SYS$MANAGER" = "SYS$SYSROOT:[SYSMGR]" (LNM$SYSTEM_TABLE)

syst-t>sh log SYS$SYSROOT

"SYS$SYSROOT" = "ALPHA1$DKC0:[SYS0.]" (LNM$SYSTEM_TABLE)
= "SYS$COMMON:"
1 "SYS$COMMON" = "ALPHA1$DKC0:[SYS0.SYSCOMMON.]" (LNM$SYSTEM_TABLE)

Notice the weird order of the files in SYS$SYSROOT:[SYSMGR] and the lack of symmetry with SYS$COMMON:[SYSMGR].

I believe that I should only be seeing SYS$COMMON:[SYSMGR] and not also SYS$SYSROOT:[SYSMGR] with the dir command. Also the updated file was put into the sys$sysroot and not into the sys$common.

Any idea what the source of the problem is and how to fix it? Thanks

[Volker Halle · Accepted solution]

sandyt,

the SYS$MANAGER logical and directory output shown in your example are PERFECTLY O.K. !

SYS$SYSROOT is a rooted directory, which is pointing to 2 locations, the system-specific one and the common one.

If you create new files and your default is set to SYS$MANAGER, the file will be created in the node-specific directory. If a file with the same name already exists in the common directory, the new version will be put put into the common directory as well.

The creation dates look a bit unusual, but we don't known how and when those file got there.

Volker.

[Gregg Parmentier]

The dates being out of order seems to me to be because someone did a copy of sylogicals.com;* from sys$common:[sysmgr} to sys$root:[sysmgr} sometime between Feb 17 and Mar 3.

[EdgarZamora]

Sandyt,

this is a common "issue" especially with systems managed by multiple system managers. Understand how sys$sysroot works and it'll all make sense. Depending on your environment (standalone systems or clustered and your system management style) you'll want to decide where you want the procedures to reside (sys$specific or sys$common) and then you should move the files over to one location. You should probably check on your other command procedures (like systartup_vms.com, syconfig.com, sysecurity.com, etc.) because you'll likely find the same situation with those files.

[Robert Gezelter]

sandyt,

The listing is normal. I agree with the suspicion that a person (or persons) have at various times copied files into one of the directories in the search path.

I would recommend extreme caution. The SYS$SYSDEVICE:[SYS0.SYSMGR] directory is first in the search list, as it should be. The SYLOGICALS.COM in the system-specific directory will be executed. However, it is also possible that the SYS$SPECIFIC:[SYSMGR]SYLOGICALS.COM in turn contains a reference to the file in SYS$COMMON:[SYSMGR].

I recommend careful review of all of these files to make sure that a change that is rarely used is not lost.

For educational purposes, I note that the actual references to SYLOGICALS.COM in the startup process are made to the SYS$STARTUP logical name, not SYS$MANAGER. SYS$STARTUP is itself a search list of SYS$SYSROOT:[SYS$STARTUP] and SYS$MANAGER.

If one is not familiar, caution is recommended. It is easy to put a file into the wrong directory and get incorrect results.

- Bob Gezelter, http://www.rlgsc.com

[Art Wiens]

WRT the weird order, what command did you use to display? Perhaps your "dir" command is showing modified dates (or something else?). SHOW SYMBOL DIR and see if it's not a "vanilla" DIRECTORY command.

Cheers,
Art

[John Gillings]

sandyt,

SYS$MANAGER and SYS$STARTUP can be very confusing. When system editing files it's best to always refer to the file via its precise name, for example:

SYS$COMMON:[SYSMGR]SYLOGICALS.COM.

If you avoid using the SYSTEM account for general management, you avoid the confusion of having your default set to a search list.

One step further, move all your cluster common files, like SYLOGICALS.COM to a common location on some other disk. Then replace all the SYS$COMMON versions of those files with stubs pointing to the common area. That way you never have to edit the files on the system disk.

This is especially helpful if you have a multi system disk cluster, as it makes sure all your nodes access a consistent cluster common environment. I tend to treat even single node systems as if they were a cluster. See SYLOGICALS.TEMPLATE for a list of cluster common files.

(Unfortunately I think we're well past the time when OpenVMS could have fixed the problem of managing cluster environment by providing a utility to deal with this kind of issue. HP appears to have given up on significant improvements. We're left with the state where individual system managers have to implement their own tools and structures, learning along the way, mostly by making mistakes precisely like the one sandyt has reported!)

[sandyt]

Thanks for all the help guys. We will try and be more careful in the future, and take your system directory suggestions to heart.