[Info-vax] Do you (or someone you work with) sysman on Windows?

[Phillip Helbig undress to reply]

In article <mjvbv2$vg$1 at dont-email.me>, Stephen Hoffman
<seaohveh at hoffmanlabs.invalid> writes: 

> Jan-Erik and a number of existing environments will probably never move 
> to clean-install processing, but other folks I'm dealing with are 
> interested, and particularly when dealing with more than one.  Once you 
> get around to deploying 300 OpenVMS servers, the Old Ways Of Doing 
> Things get... annoyingly tedious.  (That deployment number is NOT made 
> up nor picked from the air, either.)

If there is little customization, sure, always do a clean install, 
perhaps automated somehow.  But if there is customization, repeating 
this 300 times is much less than figuring out a strategy to clone disks 
cleanly.  (Hopefully, I'll soon be able to test if mine works.)

I'm probably not the only one who has multiple system disks in a 
cluster, mainly for reliability and availability, but who wants 
essentially the same setup everywhere.  SYS$SPECIFIC is for the 
individual node; perhaps more than one boots from a system disk (whether 
a satellite or more than one bootserver from a fancy disk).  SYS$COMMON 
is a mixture of stuff valid for all nodes on this disk and all VMS 
systems in the world.  There is no specific place for cluster-common 
stuff.

My approach is to have a non-system disk for cluster-common stuff.
Define the logical names, move the files there.  Things like
SYSTARTUP_VMS.COM can look for a corresponding file on the cluster disk 
and execute it.  I like to have stuff specific to system disks here, 
branching appropriately.  Why?  So I can clone SYS$COMMON.  (One can 
keep the various SYS$SPECIFIC trees in sync before cloning.)  But even 
this won't work with a fresh install.

One way it could work is to have each startup file look for an 
identically named file elsewhere and if it exists, execute it.

Actually, such files in SYS$SPECIFIC should execute the ones in
SYS$COMMON, those in SYS$COMMON in SYS$CLUSTER or whatever it will be 
called.  Thus, one can ADD more specific customizations, rather than 
COPYING the higher-level one and changing it.  One could then add 
customizations before or after the calling of the higher-level file, 
comment out this calling if desired, etc.

> But back to that earlier comment of mine: nuking and paving gets you a 
> reproducible and more easily supportable and more easily recoverable 
> environment.   OpenVMS just isn't good at that.  Other operating 
> systems are vastly better at it.

I like the idea of a fresh install, but with even a slightly customized 
environment that means even more work with the way VMS works now.