problems with sys$manager directory - 7.3-2

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/dateand this is what I find:Directory SYS$SYSROOT:[SYSMGR]

Re: problems with sys$manager directory - 7.3-2

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.

Re: problems with sys$manager directory - 7.3-2

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.

Re: problems with sys$manager directory - 7.3-2

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.

Re: problems with sys$manager directory - 7.3-2

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!)