Discussion:
SYS$SYSROOT and Local Customizations
(too old to reply)
Stephen Hoffman
2020-10-23 16:37:26 UTC
Permalink
Forking a thread...
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
Simon Clubley
2020-10-23 17:23:02 UTC
Permalink
Post by Stephen Hoffman
I look at this and wonder what happened to "simple".
The model of computing changed and VMS was sufficiently rigid that
it couldn't fully adapt easily to the new way of doing things.

VMS was created for one specific model of computing in mind and it
worked very well within that model. Then what was important changed...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
geze...@rlgsc.com
2020-10-23 17:26:55 UTC
Permalink
On Friday, October 23, 2020 at 12:37:30 PM UTC-4, Stephen Hoffman wrote:
<deleted in the interest of brevity>

Hoff,

WADR, we have different perspectives on this issue.

I will agree with you that it is important to modify the searchlist properly, fragile methods are a poor choice. I will also agree that there have been no shortage of poor choices made when designing and implementing various additions.

However, it can be done reasonably robustly, and is fairly safe. The approach has been used by a number of layered and integrated products, including the VAX-11 RSX AME and DECwindows. Other products, including a major third party database product, have had longstanding reported bugs associated with doing the modification of SYS$SYSROOT incorrectly (Personal experience. I fixed the problem, then went into the bug report database and found a reported bug involving DECwindows).

I described almost precisely the scenario described by Phillip in my OpenVMS Technical Journal paper, "Inheritance Based Environments in Stand-alone OpenVMS Systems and OpenVMS Clusters" , copy at http://www.rlgsc.com/publications/vmstechjournal/inheritance.html.

The key to properly inserting into SYS$SYSROOT and for that matter, any arbitrary search list is to not append or prepend the addition to the full translation, but to insert the new entry at the correct precedence in the search order. The lexical function F$TRNLNM is the key here, particularly the use of the Item code MAX_INDEX.

One also has to ensure that the disks containing the shared files are mounted before they are referenced. One also needs toproperly configure the STARTUP to function correctly if the shared files are not available.

Done properly, a useful techniqueue. Done without proper care, serious problems can ensue.

- Bob Gezelter, http://www.rlgsc.com
Dave Froble
2020-10-23 17:44:43 UTC
Permalink
Post by Stephen Hoffman
Forking a thread...
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.
Post by Stephen Hoffman
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.
Post by Stephen Hoffman
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.
Post by Stephen Hoffman
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Phillip Helbig (undress to reply)
2020-10-23 17:46:56 UTC
Permalink
Post by Stephen Hoffman
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.
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.
And one needs more than one system disk in a cluster in order to do a
rolling upgrade, not to mention mixed-architecture stuff.
Post by Stephen Hoffman
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.
More or less what I'm doing now.

I don't put anything on the system disk except for DEC-related stuff
which installs there by default. Dedicated disks for users, third-party
software, scratch, data, and so on.
Post by Stephen Hoffman
I don't prefer to leave local stuff in SYS$SYSROOT, though will
necessarily parallel the approach that an existing site is already
using.
I use it only for node-specific stuff.

Loading...