[Info-vax] SYS$SYSROOT and Local Customizations

[Dave Froble]

On 10/23/2020 12:37 PM, Stephen Hoffman wrote:
>
> 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".

I may have mention in the past just a bit of how much I dislike 
"clever".  I doubt I could ever put in words the magnitude of that dislike.

> 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.

While I don't run a cluster, I do feel that with some thought and study 
of usage something a bit better could be designed and implemented.  It 
ain't rocket science.  The requirements seem to be well known.

Why don't I run a cluster?  I'm a software developer.  Just about any 
computer can stay ahead of me, and it only gets easier for the computer 
each year.

> 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.

We all know Dave has strong opinions.  So I'll be clear about this. 
Anybody who mixes OS and apps is a blithering idiot.  I don't even like 
using SYS$SHARE for RTLs and such.  Too bad that makes things easier. 
It's just too easy for VSI to clobber something there, even if it hasn't 
happened yet.

Yes, I'll admit I have sinned in regard to this.  Too late now, everyone 
using the software will state "it's never happened, what's your 
problem".  My contingency plan is to have static copies and copy them 
into SYS$SHARE on system startup.

> 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".
>

What?  Did KISS die while I wasn't looking?  Next the sky will fall.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486