[Info-vax] New VSI Community license PAK

[Phillip Helbig undress to reply]

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

> > Not saying anything definite about this thought, but, right now, as I 
> > understand it, the source code for VSI Alpha VMS V8.4 2L1 and VSI Alpha 
> > VMS V8.4 2L2 is exactly the same.  No differences.  2L2 was compiled 
> > with compiler switches to use EV6 instructions, which I seem to recall 
> > Clair mentioned that it had a performance increase just in the OS of 
> > around 15%.  So a version without the EV6 only instructions should run 
> > on any "supported" Alpha HW.  Not getting into anything like the Multia.
> 
> There were other changes.
> 
> VSI OpenVMS Alpha V8.4-2L2 is the first OpenVMS Alpha release that can 
> be installed.
> 
> VSI OpenVMS Alpha V8.4-2L1 only works as an upgrade. Not as an install.

Good to keep in mind.  I'd probably prefer two upgrades to a fresh 
install.  :-|

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.

> Past the OpenVMS I64 V8.4-2L3 update / roll-up / remaster, I wouldn't 
> expect to see more than maintenance on Alpha and Itanium.

Which is good, in a way.  :-)