[Info-vax] SYS$SYSROOT and Local Customizations

[Stephen Hoffman]

Forking a thread...

On 2020-10-23 08:47:59 +0000, Phillip Helbig (undress to reply said:

> When I move to x86, I'll seriously consider putting a non-system disk 
> between SYS$SPECIFIC and SYS$COMMON in the definition of SYS$SYSROOT.  
> I realize that this is a pretty low-level customization, but I've heard 
> of other people doing it and I see no reason why it wouldn't work if 
> the software specifies SYS$SYSROOT (or something pointing to it), as it 
> should.  SYS$COMMON is a mix of stuff common to all nodes booting from 
> that disk and stuff common to all VMS systems in the world.  The 
> personality" of my system are things specific to my cluster.  Thus, 
> they should be picked up before the default stuff in SYS$COMMON.  Now, 
> I mount a non-system disk from SYLOGICALS.COM and execute a startup 
> procedure there.  All the stuff mentioned in SYLOGICAL.COM which can be 
> moved off the system disk and specified by logical names is on that 
> non-system disk, as well as stuff like operator and audit logs and 
> TCPIP stuff.  Procedures in SYS$COMMON which have a modified copy on 
> the non-system disk have been modified to check for the existence of 
> the latter and, if found, execute them.  Same result once set up, but I 
> don't want to have to go through it again---for each system 
> disk---after a fresh install, hence the preference for upgrades.  Yes, 
> fresh installs  can get rid of cruft, but I might need to keep some of 
> that cruft.  In any case, I'll have to do a fresh install on x86.

I despise this whole "design" within clustering, and I prefer to avoid 
being "clever" while in proximity to the "design". It's way too easy to 
miss one or two files, and weirdness ensues. And there are layered 
products which do a poor job of documenting prolly-should-be-shared 
files. And others which dump everything into SYS$SPECIFIC on each host. 
One of those loaded a full Java, and then didn't maintain it. And this 
"cleverness" can trip up other packages, that are "differently-clever".

Relocating the cluster configuration and authorization files via 
logical name is a (necessary) hack for any configuration that has or 
might have more than one system disk. More subtly, this also requires 
the core authorization files be moved back to the system disk. Most 
folks ignore that whole back-to-the-system-disk requirement when 
upgrading. Though there have been cases where that's bitten folks. And 
the whole cluster rolling upgrade process runs afoul of the usual RMS 
baggage. Where adding another file is easier than modifying existing 
files.

That is, I prefer to keep the local customizations and local files 
separate, using shims in the SY* files to access the production 
startups, and logical names to redirect.

The shim procedures mount the common disk (if required) and then access 
and invoke the customizations in files there. And reference the 
authorization and cluster configuration files there, too.

I don't prefer to leave local stuff in SYS$SYSROOT, though will 
necessarily parallel the approach that an existing site is already 
using.

Keep my customizations and my apps separate. This allows better 
targeting of backups, and allows VSI to do whatever they might want to 
this morass—including what are likely breaking changes to 
authorization-related files, as has been discussed—and avoids tripping 
code that parses logical names. I then use logical names, or DCL$PATH 
to activate the associated executables or DCL procedures; binaries or 
shell scripts.

Parsing logical names? I prefer to avoid modify SYS$SYSROOT, as I've 
written code that parses that, and have met other examples performing 
that are, well, fragile. Some versions add a translation at the end of 
the searchlist logical name translation list, some in the middle as 
you're considering. Haven't yet run into one at the front of the 
translation list, but that prolly exists.

And yes, this whole area has been discussed before. Repeatedly. And 
OpenVMS development has discussed adding site-local translations, 
though that was obviously released. Some OpenVMS development clusters 
did what you suggest here with adding a SYS$SYSROOT translation, too, 
so opinions differ.

My apps get their own directory, and minimal ties to the OpenVMS system 
directories—and those modifications would largely or entirely disappear 
with PCSI or VMSINSTAL integration with startup and shutdown, but 
that's not happening any time soon.

I look at this and wonder what happened to "simple".

-- 
Pure Personal Opinion | HoffmanLabs LLC