[Info-vax] IS everyone waiting?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Phillip Helbig undress to reply via Info-vax
> Sent: 20-Oct-16 7:28 AM
> To: info-vax at rbnsn.com
> Cc: Phillip Helbig undress to reply
> <helbig at asclothestro.multivax.de>
> Subject: Re: [Info-vax] IS everyone waiting?
> 
> In article <558780b0-b6c1-4d38-839a-
> d0de358f938e at googlegroups.com>,
> abrsvc <dansabrservices at yahoo.com> writes:
> 
> > > I remember the promise of VSI to support (at least) Alpha
and
> X46
> > > (and=20
> > > Itanium) in a mixed-architecture cluster.
> >
> > There was some discussion about this at the bootcamp this
> year.  IRRC,
> > the = result was that mixed clusters would be supported and
> that VSI
> > versions of = the software would likely be required. And yes,
> this
> > includes an Alpha vers= ion.  This may require an upgrade to
> V8.4 though.
> 
> Yes, 8.4.  Perhaps some special 8.4.x.
> 
> I went to from 7.3-2 to 8.4 on one machine, but since
> DECwindows stopped working, I haven't upgraded the others.  It
> would take some time to solve the problem, and by then X86
> might be available, where I'll have to do a fresh install
anyway.
> Yes, VMS on x86 won't support high-end graphics, but the on-
> chip graphics will be used for DECwindows, which is probably
all I
> need.
> 

Well, when one does the equivalent of an upgrade from Windows NT4
to Windows Server 2012, it is reasonable to expect some issues
that may need to be tweaked.

Troubleshooting something like why something as basic as
DECwindows not starting up is usually not a complex task.

> (I could do a fresh install of 8.4 and see what happens, but
that
> would mean having to add back in various customizations and so
> on.  It would be nice if one could easily do an almost fresh
install,
> i.e. separate the system disk into stuff which really needs to
be
> changed in an upgrade, and other stuff which is customizable.
> I've done this to a large extent already in order to make it
easier
> to clone a system disk, but this requires some changes on the
> system disk which a fresh install would overwrite.  On a
related
> note, SYS$COMMON is a mixture of stuff shared by all nodes
> booting from that system disk and stuff shared by all VMS
> systems in the world.  In a cluster with more than one system
> disk, there is a need for a non-system disk common to all nodes
in
> the cluster where stuff like SYS$SYLOGIN, SYSUAF and so on can
> reside.  This can be done, but folks roll their own.  One can
> redefine SYS$SYSROOT, but this can be tricky.  Also, this would
> give a fixed order for the translations, which might not be
always
> appropriate.)
> 

Not sure what the point is. 

When any OpenVMS customer uses common system disks in a cluster,
the recommendation is to setup a common non-system disk between
the OS instances to share common files. That's a decades old best
practice for the OpenVMS community. 

Reference sect 11.3:
http://h41379.www4.hpe.com/doc/82final/6318/6318pro_020.html 

While automating this might seem like a benefit, many Cust's
would also argue that because of all the various custom config's,
this is better left to the local SysAdmin.

Setting up a OpenVMS cluster has lots of benefits, but like every
OS platform, OpenVMS clusters do require more planning and work
to setup and configure than an individual system.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com