Discussion:
New VSI Community license PAK
(too old to reply)
Chris Townley
2020-10-20 09:51:14 UTC
Permalink
Just received the following from VSI:

"After analyzing the feedback given by the participants of the Community
License program, VMS Software has made the decision to remove the
limitations imposed by the previous version of the license.

This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system and the Integrity license will include HBVS
and clustering until further notice. However, the Community License
Agreement remains unchanged, so any commercial use of the operating
system is strictly forbidden and those who are interested in commercial
scenarios are eligible to a common or ISV license that can be agreed
with the sales department."

New alpha PAK was attached

Sounds good

Chris
Hans Bachner
2020-10-20 10:31:13 UTC
Permalink
Post by Chris Townley
"After analyzing the feedback given by the participants of the Community
License program, VMS Software has made the decision to remove the
limitations imposed by the previous version of the license.
This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system and the Integrity license will include HBVS
and clustering until further notice. However, the Community License
Agreement remains unchanged, [...]"
New alpha PAK was attached
Sounds good
Chris
Great news, indeed. I also received this email just minutes ago.

Thanks for listening, VSI!

Hans.
Jairo Alves
2020-10-20 12:09:31 UTC
Permalink
nice
Arne Vajhøj
2020-10-20 13:52:21 UTC
Permalink
Post by Hans Bachner
Post by Chris Townley
"After analyzing the feedback given by the participants of the
Community License program, VMS Software has made the decision to
remove the limitations imposed by the previous version of the license.
This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system and the Integrity license will include
HBVS and clustering until further notice. However, the Community
License Agreement remains unchanged, [...]"
New alpha PAK was attached
Great news, indeed. I also received this email just minutes ago.
Thanks for listening, VSI!
That seems to be the VSI MO - listening and act based on the feedback.

Cool.

Arne
Phillip Helbig (undress to reply)
2020-10-20 12:08:31 UTC
Permalink
Post by Chris Townley
"After analyzing the feedback given by the participants of the Community
License program, VMS Software has made the decision to remove the
limitations imposed by the previous version of the license.
Great! Well done!
Post by Chris Townley
This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system
As far as the number of units go, yes, but presumably the VSI license
makes sense only with VSI VMS and the latter requires a reasonably new
CPU, right? At least EV6/21264?
Post by Chris Townley
and the Integrity license will include HBVS
and clustering until further notice.
Great!
Post by Chris Townley
However, the Community License
Agreement remains unchanged, so any commercial use of the operating
system is strictly forbidden and those who are interested in commercial
scenarios are eligible to a common or ISV license that can be agreed
with the sales department."
Sensible, and that's the way it has always been.

The question now is whether the Community License for x86 will include
clustering and HBVS. Presumably the only people with non-commercial
licenses running VSI VMS on Alpha or Integrity are those planning to
eventually move to x86.
Chris Townley
2020-10-20 12:25:36 UTC
Permalink
Post by Phillip Helbig (undress to reply)
As far as the number of units go, yes, but presumably the VSI license
makes sense only with VSI VMS and the latter requires a reasonably new
CPU, right? At least EV6/21264?
I believe EV5 is OK - I am intending to move my PWS433AU there.

FreeAXP, in which I am running V8.4-2L1 show as:

CPU - State..........: RC, PA, PP, CV, PV, PMV, PL
Type...........: EV4 (21064), Pass 2 or 2.1
Speed..........: 1216 Mhz

which seems to work well

Chris
Hans Bachner
2020-10-20 14:22:18 UTC
Permalink
Post by Chris Townley
Post by Phillip Helbig (undress to reply)
As far as the number of units go, yes, but presumably the VSI license
makes sense only with VSI VMS and the latter requires a reasonably new
CPU, right?  At least EV6/21264?
I believe EV5 is OK - I am intending to move my PWS433AU there.
     CPU     -  State..........: RC, PA, PP, CV, PV, PMV, PL
                Type...........: EV4 (21064), Pass 2 or 2.1
                Speed..........: 1216 Mhz
which seems to work well
Chris
Yes, but... it seems that FreeAXP is cheating a bit, as a FreeAXP
Post by Chris Townley
STUDNT> sho sys /full /noproc
OpenVMS V8.4-2L2 on node STUDNT 20-OCT-2020 16:02:18.05 Uptime 0 00:38:23
AlphaServer 400 4/166
So this EV4/166 CPU is clearly executing EV6 instructions...

Leaving alone what VSI mentions as supported (presumably: tested)
hardware, I'd assume that V8.4-1L1 runs on any Alpha which was supported
by HPE OpenVMS V8.4. I don't think that VSI removed any existing
hardware support for older systems.

The hardware requirements of V8.4-2L2 are there because of the compiler
switches used to build the system - which trigger usage of instructions
only available in EV6 and above.

Hans.
Phillip Helbig (undress to reply)
2020-10-20 16:10:33 UTC
Permalink
Post by Chris Townley
Post by Phillip Helbig (undress to reply)
As far as the number of units go, yes, but presumably the VSI license
makes sense only with VSI VMS and the latter requires a reasonably new
CPU, right? At least EV6/21264?
I believe EV5 is OK - I am intending to move my PWS433AU there.
CPU - State..........: RC, PA, PP, CV, PV, PMV, PL
Type...........: EV4 (21064), Pass 2 or 2.1
Speed..........: 1216 Mhz
which seems to work well
Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.
Dave Froble
2020-10-20 17:32:41 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Chris Townley
Post by Phillip Helbig (undress to reply)
As far as the number of units go, yes, but presumably the VSI license
makes sense only with VSI VMS and the latter requires a reasonably new
CPU, right? At least EV6/21264?
I believe EV5 is OK - I am intending to move my PWS433AU there.
CPU - State..........: RC, PA, PP, CV, PV, PMV, PL
Type...........: EV4 (21064), Pass 2 or 2.1
Speed..........: 1216 Mhz
which seems to work well
Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.
That doesn't make any sense.

At the level of clustering the individual system architecture should not
matter. Just the capabilities of the software.
--
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-20 17:37:35 UTC
Permalink
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.
That doesn't make any sense.
At the level of clustering the individual system architecture should not
matter. Just the capabilities of the software.
I need to come up with a migration path from mixed EV56/EV6 cluster with
VMS 7.3-2 and 8.4 to VMS auf x86. It can't be done in one step.

The basic idea is to build a mixed-architecture cluster with HBVS
members on nodes of both types, then gradually move to shadowset members
only on x86 nodes then move to only x86 nodes.

I can't cluster what I have now with x86 VMS. I at least have to go to
VSI VMS. But I'm pretty sure that I have to go to EV6 for that. So
maybe it's not clustering which requires an architecture, but rather
clustering (in the special case of mixed versions and mixed
architectures) requiring a version of VMS which in turn requires some
minimum hardware version.

Even if I could plug my SBB disks into x86, I wouldn't do it, since I
still need a mixed-architecture cluster to compile and compare before
switching off the ALPHAs. (This is similar to how I went from VAX to
Alpha.)
John H. Reinhardt
2020-10-20 18:26:59 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.
That doesn't make any sense.
At the level of clustering the individual system architecture should not
matter. Just the capabilities of the software.
I need to come up with a migration path from mixed EV56/EV6 cluster with
VMS 7.3-2 and 8.4 to VMS auf x86. It can't be done in one step.
The basic idea is to build a mixed-architecture cluster with HBVS
members on nodes of both types, then gradually move to shadowset members
only on x86 nodes then move to only x86 nodes.
I can't cluster what I have now with x86 VMS. I at least have to go to
VSI VMS. But I'm pretty sure that I have to go to EV6 for that. So
maybe it's not clustering which requires an architecture, but rather
clustering (in the special case of mixed versions and mixed
architectures) requiring a version of VMS which in turn requires some
minimum hardware version.
Even if I could plug my SBB disks into x86, I wouldn't do it, since I
still need a mixed-architecture cluster to compile and compare before
switching off the ALPHAs. (This is similar to how I went from VAX to
Alpha.)
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up so you should be okay.
--
John H. Reinhardt
Phillip Helbig (undress to reply)
2020-10-20 19:25:48 UTC
Permalink
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
Robert A. Brooks
2020-10-20 19:40:51 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
You will need patches to V8.4-2Lx to cluster with X86.

We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join
a cluster with V9.2.

That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
--
-- Rob
Phillip Helbig (undress to reply)
2020-10-20 21:19:48 UTC
Permalink
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
You will need patches to V8.4-2Lx to cluster with X86.
We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join
a cluster with V9.2.
That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
OK. So I have the following steps:

1. Move all nodes in Alpha cluster to EV6 or better.

2. Upgrade all nodes in Alpha cluster to V8.4-2Lx + patches.

3. Add x86 nodes to cluster.

4. Add shadow-set members served by x86 nodes to cluster.

5. Adapt startup to x86 if necessary.

6. Compile code on x86 and test.

7. Remove shadow-set members connected to Alpha nodes.

8. Remove Alpha nodes from cluster.

Step 6. could be moved to between steps 3. and 4.

Did I miss anything?

The unknown (at least to me) point at the moment is whether the x86
community license will include HBVS and clustering and compilers. :-|

I need to get as far as 2. before hobbyist licenses expire, but that
shouldn't be a problem. Of course, the goal is to move to x86, which I
would want to do even if the community license for Alpha were
perpetually available (or had no termination date). However, before
starting on this amazing journey it would be good to know if I can have
all the features I use via the hobbyist license now via the community
license on x86 (and, for the transition period, Alpha).
Jan-Erik Söderholm
2020-10-20 21:57:30 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
You will need patches to V8.4-2Lx to cluster with X86.
We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join
a cluster with V9.2.
That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
1. Move all nodes in Alpha cluster to EV6 or better.
2. Upgrade all nodes in Alpha cluster to V8.4-2Lx + patches.
3. Add x86 nodes to cluster.
4. Add shadow-set members served by x86 nodes to cluster.
5. Adapt startup to x86 if necessary.
6. Compile code on x86 and test.
7. Remove shadow-set members connected to Alpha nodes.
8. Remove Alpha nodes from cluster.
Step 6. could be moved to between steps 3. and 4.
Did I miss anything?
The unknown (at least to me) point at the moment is whether the x86
community license will include HBVS and clustering and compilers. :-|
I need to get as far as 2. before hobbyist licenses expire, but that
shouldn't be a problem. Of course, the goal is to move to x86, which I
would want to do even if the community license for Alpha were
perpetually available (or had no termination date). However, before
starting on this amazing journey it would be good to know if I can have
all the features I use via the hobbyist license now via the community
license on x86 (and, for the transition period, Alpha).
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
abrsvc
2020-10-20 22:02:51 UTC
Permalink
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
Jan-Erik Söderholm
2020-10-20 22:26:17 UTC
Permalink
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
Per the note from Robert Brooks, 8.4-2lx with patches will be required to
be in a cluster with the x86 version.
Robert A. Brooks
2020-10-20 23:53:51 UTC
Permalink
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
Per the note from Robert Brooks, 8.4-2lx with patches will be required to be in a cluster with the x86 version.
+1
--
-- Rob
Dave Froble
2020-10-21 00:05:01 UTC
Permalink
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
No, Robert used "2Lx", which I take to be both 2L1 and 2L2.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
abrsvc
2020-10-21 10:28:22 UTC
Permalink
Post by Dave Froble
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
No, Robert used "2Lx", which I take to be both 2L1 and 2L2.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
You are correct and I misread the note. It would appear that both variants will be patched as you (and Robert) indicated. My error.
Dave Froble
2020-10-21 13:57:59 UTC
Permalink
Post by abrsvc
Post by Dave Froble
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
No, Robert used "2Lx", which I take to be both 2L1 and 2L2.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
You are correct and I misread the note. It would appear that both variants will be patched as you (and Robert) indicated. My error.
I will confess that I don't6 know all the ramifications, but, I do
wonder why VSI doesn't just issue a new version of VMS instead of a
patch for an existing version. The end result would be the same, but
new installs would require an immediate patch.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
abrsvc
2020-10-21 14:12:07 UTC
Permalink
Post by Dave Froble
Post by abrsvc
Post by Dave Froble
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required to be in a cluster with the x86 version.
No, Robert used "2Lx", which I take to be both 2L1 and 2L2.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
You are correct and I misread the note. It would appear that both variants will be patched as you (and Robert) indicated. My error.
I will confess that I don't6 know all the ramifications, but, I do
wonder why VSI doesn't just issue a new version of VMS instead of a
patch for an existing version. The end result would be the same, but
new installs would require an immediate patch.
--
David Froble Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
It sounds like the patch is required only if you wish to cluster Alpha systems with the X86 versions since the cluster interconnect code will be changed. This does not prevent any systems from communicating or working with other versions, just not in a cluster.

I maintain multiple versions for support reasons. Yes a cluster is convenient when testing mutiple versions using shared disks etc., but not necessary. I don't see any reason for a complete install when there are likely few files that would be changed. A patch is reasonable, smaller and quicker to install.
Jan-Erik Söderholm
2020-10-21 15:32:32 UTC
Permalink
Post by Dave Froble
Post by abrsvc
Post by Jan-Erik Söderholm
Why step 1? V8.4-2L1 runs on more or less any Alpha. To make it easier,
use 8.4-2L1 on all Alphas, even if 8.4-2L2 *could* run on some.
Per the note from Robert Brooks, 8.4-2l2 with patches will be required
to be in a cluster with the x86 version.
No, Robert used "2Lx", which I take to be both 2L1 and 2L2.
--
David Froble                       Tel: 724-529-0450
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486
You are correct and I misread the note.  It would appear that both
variants will be patched as you (and Robert) indicated.  My error.
I will confess that I don't6 know all the ramifications, but, I do wonder
why VSI doesn't just issue a new version of VMS instead of a patch for an
existing version.  The end result would be the same, but new installs would
require an immediate patch.
I would expect a total upgrade to need much more downtime. A patch is
usually a quick install and a reboot. It is only small parts of VMS
that are changed by this patch, after all.

A new version would also force such as Oracle to re-validate Rdb on
the new VMS version. And probably release a new version of Rdb that
has support for the new VMS version in it's version control.

No, just patching the cluster parts seems far easier.
Dave Froble
2020-10-21 00:03:14 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
You will need patches to V8.4-2Lx to cluster with X86.
We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join
a cluster with V9.2.
That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
1. Move all nodes in Alpha cluster to EV6 or better.
You just ain't getting it, are you Phillip?

As long as the patches are for both 2L1 and 2L2, as Robert has indicated
with "2Lx", EV6 is irrelevant.
--
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-21 05:13:32 UTC
Permalink
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
1. Move all nodes in Alpha cluster to EV6 or better.
You just ain't getting it, are you Phillip?
I don't know, which is why I'm asking.
Post by Dave Froble
As long as the patches are for both 2L1 and 2L2, as Robert has indicated
with "2Lx", EV6 is irrelevant.
Other responses have indicated that I do need EV6.
Hans Bachner
2020-10-21 08:16:04 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
1. Move all nodes in Alpha cluster to EV6 or better.
You just ain't getting it, are you Phillip?
I don't know, which is why I'm asking.
Post by Dave Froble
As long as the patches are for both 2L1 and 2L2, as Robert has indicated
with "2Lx", EV6 is irrelevant.
Other responses have indicated that I do need EV6.
Which responses?

Hans.
Dave Froble
2020-10-21 13:59:49 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
1. Move all nodes in Alpha cluster to EV6 or better.
You just ain't getting it, are you Phillip?
I don't know, which is why I'm asking.
Post by Dave Froble
As long as the patches are for both 2L1 and 2L2, as Robert has indicated
with "2Lx", EV6 is irrelevant.
Other responses have indicated that I do need EV6.
I don't recall any "valid" responses that indicate that. Yes, a
mistake, but later corrected.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2020-10-20 23:59:22 UTC
Permalink
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
You will need patches to V8.4-2Lx to cluster with X86.
We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join
a cluster with V9.2.
That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
Let me guess, Steve's harping on security, right?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-10-21 12:20:39 UTC
Permalink
Post by Dave Froble
Post by Robert A. Brooks
We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join
a cluster with V9.2.
That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
Let me guess, Steve's harping on security, right?
VSI have stated they are moving to using a more secure cluster protocol.

They are also replacing Purdy with a far less efficient and much more
compute intensive algorithm.

Both of those are good things and are long overdue.

Now if they could just get people to stop using DECnet Phase IV...

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Stephen Hoffman
2020-10-21 20:02:20 UTC
Permalink
Post by Dave Froble
Post by Robert A. Brooks
You will need patches to V8.4-2Lx to cluster with X86.
We are planning on making incompatible changes to the cluster protocol
that will require a cluster compatibility kit in order to join a
cluster with V9.2.
That will prevent any HPE version of VMS from clustering with V9.2, but
that's not the reason for the change.
Let me guess, Steve's harping on security, right?
"The most secure operating system on the planet" wasn't my idea, David.

VSI does now have access to faster cryptographic processing, with
semi-recent x86-64 hardware.

I'm not expecting ~V9.2 NISCS traffic encrypted and authenticated,
though that'd be nice—if VSI can maintain performance. Yes, IPSCS
traffic does get encrypted, and that implementation could use some work.

Kernel support for TLS and DTLS would be also interesting, but the SCS
adoption of that or of ZRTP or ilk would be unexpected.

I'd expect this change is due to other updates and enhancements to
clustering protocols, something that happened occasionally in previous
releases. e.g. DLM-related changes.

But we'll know when VSI tells us.
--
Pure Personal Opinion | HoffmanLabs LLC
Simon Clubley
2020-10-22 12:25:06 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
Let me guess, Steve's harping on security, right?
"The most secure operating system on the planet" wasn't my idea, David.
I _really_ hope VSI stop doing that _before_ x86-64 VMS becomes
generally available.
Post by Stephen Hoffman
Kernel support for TLS and DTLS would be also interesting, but the SCS
adoption of that or of ZRTP or ilk would be unexpected.
A kernel-level random number device driver would be nice as well.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Phillip Helbig (undress to reply)
2020-10-22 14:40:39 UTC
Permalink
Post by Simon Clubley
A kernel-level random number device driver would be nice as well.
Random numbers are too important for their generation to be left to
chance. :-)
Simon Clubley
2020-10-22 17:58:41 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
A kernel-level random number device driver would be nice as well.
Random numbers are too important for their generation to be left to
chance. :-)
You are clearly making a joke, but that is exactly why they should
be generated within the operating system kernel, where the algorithm
can be reviewed and where the random number generator has access to
system activity.

The Linux random number generator has undergone this level of scrutiny:

https://en.wikipedia.org/wiki//dev/random#Linux

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Craig A. Berry
2020-10-23 20:52:59 UTC
Permalink
Post by Simon Clubley
Post by Phillip Helbig (undress to reply)
Post by Simon Clubley
A kernel-level random number device driver would be nice as well.
Random numbers are too important for their generation to be left to
chance. :-)
You are clearly making a joke, but that is exactly why they should
be generated within the operating system kernel, where the algorithm
can be reviewed and where the random number generator has access to
system activity.
https://en.wikipedia.org/wiki//dev/random#Linux
Page 7 of the current roadmap lists something called an "entropy engine"
for OpenVMS v9.2. Dunno anything else about it but I hope they pay up
on on the licensing fees to the Daleks because those are folks you don't
want coming after you:

<https://tardis.fandom.com/wiki/Entropy_engine>
Phillip Helbig (undress to reply)
2020-10-24 03:32:22 UTC
Permalink
Post by Craig A. Berry
Page 7 of the current roadmap lists something called an "entropy engine"
for OpenVMS v9.2. Dunno anything else about it but I hope they pay up
on on the licensing fees to the Daleks because those are folks you don't
<https://tardis.fandom.com/wiki/Entropy_engine>
At least it's a better name than Turbo Laser. :-)
Scott Dorsey
2020-10-24 12:41:33 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Craig A. Berry
Page 7 of the current roadmap lists something called an "entropy engine"
for OpenVMS v9.2. Dunno anything else about it but I hope they pay up
on on the licensing fees to the Daleks because those are folks you don't
<https://tardis.fandom.com/wiki/Entropy_engine>
At least it's a better name than Turbo Laser. :-)
That was just an upgraded Dodge Daytona.
--scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
Dave Froble
2020-10-20 23:57:59 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
VSI OpenVMS V8.4-2L1 which is what VSI gives to the CLP users is
compatible with EV56 and up Alphas. It's V8.4-2L2 which is EV6 and up
so you should be okay.
But I need V8.4-2L2 to cluster Alpha with x86, right?
No, and, it won't work anyway if the cluster interconnect stuff is changed.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Dave Froble
2020-10-20 23:56:29 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.
That doesn't make any sense.
At the level of clustering the individual system architecture should not
matter. Just the capabilities of the software.
I need to come up with a migration path from mixed EV56/EV6 cluster with
VMS 7.3-2 and 8.4 to VMS auf x86. It can't be done in one step.
When VMS Cluster is available on x86, it is my understanding that you
will be able to form a cluster with both HW types.

If the cluster software on x86 is different, and I seem to recall
reading it will be different, then an Alpha will only be able to form a
cluster with x86 if the Alpha is running whatever version of VMS that
VSI would release in the future to allow such a cluster. That Alpha VMS
release doesn't exist right now, at least in the wild.
Post by Phillip Helbig (undress to reply)
The basic idea is to build a mixed-architecture cluster with HBVS
members on nodes of both types, then gradually move to shadowset members
only on x86 nodes then move to only x86 nodes.
When VSI is ready for this to happen, it should be doable.
Post by Phillip Helbig (undress to reply)
I can't cluster what I have now with x86 VMS. I at least have to go to
VSI VMS. But I'm pretty sure that I have to go to EV6 for that.
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.

So, I don't have any idea where you got that EV6 only concept ....
Post by Phillip Helbig (undress to reply)
So
maybe it's not clustering which requires an architecture, but rather
clustering (in the special case of mixed versions and mixed
architectures) requiring a version of VMS which in turn requires some
minimum hardware version.
VSI is sort of busy, so, I don't see them taking any time to remove any
support for older HW.
Post by Phillip Helbig (undress to reply)
Even if I could plug my SBB disks into x86, I wouldn't do it, since I
still need a mixed-architecture cluster to compile and compare before
switching off the ALPHAs. (This is similar to how I went from VAX to
Alpha.)
You're going to want new storage on x86, perhaps SSD, or a mixture of
SSD and HHD.
--
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-21 05:12:21 UTC
Permalink
Post by Dave Froble
You're going to want new storage on x86, perhaps SSD, or a mixture of
SSD and HHD.
That goes without saying.
Phillip Helbig (undress to reply)
2020-10-21 10:12:23 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
You're going to want new storage on x86, perhaps SSD, or a mixture of
SSD and HHD.
That goes without saying.
Probably some substantially larger disks as well.

I might run into a limit on my 36-GB disks before then; if so I'll have
to investigate putting larger-capacity disks in an SBB, since otherwise
I would have to form a volume set and I really don't want to do that.
Chris Scheers
2020-10-21 20:52:39 UTC
Permalink
I think everyone is over thinking this.

From what has been said, it seems that this is NOT an x86 issue.

It is a VMS 9.2 issue.

For a 9.2 node to cluster with a 8.4 node, the 8.4 node will need a
patch kit to update the cluster code.

This is irrespective of the underlying hardware.

Please correct me if I am misunderstanding this.

What I am waiting to see is for all SCS traffic to be encrypted. In
this case, the encryption certificate can replace the cluster password.
That is, if you have the certificate, you can join the cluster.
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Post by Dave Froble
Post by Phillip Helbig (undress to reply)
Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.
That doesn't make any sense.
At the level of clustering the individual system architecture should not
matter. Just the capabilities of the software.
I need to come up with a migration path from mixed EV56/EV6 cluster with
VMS 7.3-2 and 8.4 to VMS auf x86. It can't be done in one step.
When VMS Cluster is available on x86, it is my understanding that you
will be able to form a cluster with both HW types.
If the cluster software on x86 is different, and I seem to recall
reading it will be different, then an Alpha will only be able to form a
cluster with x86 if the Alpha is running whatever version of VMS that
VSI would release in the future to allow such a cluster. That Alpha VMS
release doesn't exist right now, at least in the wild.
Post by Phillip Helbig (undress to reply)
The basic idea is to build a mixed-architecture cluster with HBVS
members on nodes of both types, then gradually move to shadowset members
only on x86 nodes then move to only x86 nodes.
When VSI is ready for this to happen, it should be doable.
Post by Phillip Helbig (undress to reply)
I can't cluster what I have now with x86 VMS. I at least have to go to
VSI VMS. But I'm pretty sure that I have to go to EV6 for that.
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.
So, I don't have any idea where you got that EV6 only concept ....
Post by Phillip Helbig (undress to reply)
So
maybe it's not clustering which requires an architecture, but rather
clustering (in the special case of mixed versions and mixed
architectures) requiring a version of VMS which in turn requires some
minimum hardware version.
VSI is sort of busy, so, I don't see them taking any time to remove any
support for older HW.
Post by Phillip Helbig (undress to reply)
Even if I could plug my SBB disks into x86, I wouldn't do it, since I
still need a mixed-architecture cluster to compile and compare before
switching off the ALPHAs. (This is similar to how I went from VAX to
Alpha.)
You're going to want new storage on x86, perhaps SSD, or a mixture of
SSD and HHD.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Robert A. Brooks
2020-10-21 21:01:55 UTC
Permalink
Post by Chris Scheers
I think everyone is over thinking this.
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
--
-- Rob
Jan-Erik Söderholm
2020-10-21 21:06:44 UTC
Permalink
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
 From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
Right. But... Maybe Alpha 8.4-2Lx still needed those patches "a week ago"
when 9.2 was still planed for Alpha? I think that was what Chris meant...

Today, with x86 being the only platform for 9.2, well, you are right... :-)
Chris Scheers
2020-10-22 00:25:27 UTC
Permalink
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
V9.2 may currently imply x86, but things can and do change.

Whatever platform 9.2 is released on (x86, Alpha, Itanium, RPi,
whatever), 8.4 would require patches to cluster with a 9.2 system. It
is the cluster protocol that is the issue, not an x86 chip.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Phillip Helbig (undress to reply)
2020-10-22 14:39:52 UTC
Permalink
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
So I can run V8.4-2L1 on any Alpha (at least EV56 or better) and cluster
with 9.x if I have the patch?
Robert A. Brooks
2020-10-22 15:33:26 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
So I can run V8.4-2L1 on any Alpha (at least EV56 or better) and cluster
with 9.x if I have the patch?
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.

We cannot release any patches for any non-VSI version of VMS.
--
-- Rob
Arne Vajhøj
2020-10-22 15:47:46 UTC
Permalink
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
  From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
So I can run V8.4-2L1 on any Alpha (at least EV56 or better) and cluster
with 9.x if I have the patch?
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
We cannot release any patches for any non-VSI version of VMS.
So the short version is:

older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2

?

Arne
Craig A. Berry
2020-10-22 15:59:23 UTC
Permalink
Post by Arne Vajhøj
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
I don't believe there is a 8.4-2L2 on Itanium. The only reason the "L2"
version exists for Alpha is for the performance boost on EV6 and later
and there is no equivalent scenario on IA64.
Jan-Erik Söderholm
2020-10-22 16:04:31 UTC
Permalink
Post by Arne Vajhøj
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
I don't believe there is a 8.4-2L2 on Itanium.  The only reason the "L2"
version exists for Alpha is for the performance boost on EV6 and later and
there is no equivalent scenario on IA64.
So:

older Alpha & Itanium => run VSI 8.4-2L1
newer Alpha => run VSI 8.4-2L2
Craig A. Berry
2020-10-22 16:30:32 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
I don't believe there is a 8.4-2L2 on Itanium.  The only reason the
"L2" version exists for Alpha is for the performance boost on EV6 and
later and there is no equivalent scenario on IA64.
older Alpha & Itanium => run VSI 8.4-2L1
newer Alpha  => run VSI 8.4-2L2
I'm not sure the L2 release is available to hobbyists, but I haven't
really gone looking for it. And by this time next year, Itanium users
should be running 8.4-2L3 (which will not be produced for Alpha).
John H. Reinhardt
2020-10-22 17:51:47 UTC
Permalink
Post by Craig A. Berry
I'm not sure the L2 release is available to hobbyists, but I haven't
really gone looking for it.  And by this time next year, Itanium users
should be running 8.4-2L3 (which will not be produced for Alpha).
It's not. The CLP downloads are only V8.4-2L1 for both Alpha and Itanium.

I wouldn't mind V8.4-2L2 for my DS10's and XP1000's. Hint hint.
--
John H. Reinhardt
Dave Froble
2020-10-22 21:06:08 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Craig A. Berry
Post by Arne Vajhøj
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
I don't believe there is a 8.4-2L2 on Itanium. The only reason the
"L2" version exists for Alpha is for the performance boost on EV6 and
later and there is no equivalent scenario on IA64.
older Alpha & Itanium => run VSI 8.4-2L1
newer Alpha => run VSI 8.4-2L2
To be precise, all Alphas will run 2L1

Only EV6 and EV7 will run 2L2, as it is compiled to use EV6 instructions
not available on pre-EV6 CPUs.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Jan-Erik Söderholm
2020-10-22 21:07:52 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Arne Vajhøj
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
I don't believe there is a 8.4-2L2 on Itanium.  The only reason the
"L2" version exists for Alpha is for the performance boost on EV6 and
later and there is no equivalent scenario on IA64.
older Alpha & Itanium => run VSI 8.4-2L1
newer Alpha  => run VSI 8.4-2L2
To be precise, all Alphas will run 2L1
Only EV6 and EV7 will run 2L2, as it is compiled to use EV6 instructions
not available on pre-EV6 CPUs.
Right...

Any Alpha & Itanium => run VSI 8.4-2L1
Newer Alpha => run VSI 8.4-2L2
Dave Froble
2020-10-22 21:03:10 UTC
Permalink
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
So I can run V8.4-2L1 on any Alpha (at least EV56 or better) and cluster
with 9.x if I have the patch?
We expect that V8.4-2L1 will work on any Alpha; we did not test
against anything older than
XP1000's.
We cannot release any patches for any non-VSI version of VMS.
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
There is no 2L2 for the itanic ....

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Craig A. Berry
2020-10-22 21:04:24 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
  From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
So I can run V8.4-2L1 on any Alpha (at least EV56 or better) and cluster
with 9.x if I have the patch?
We expect that V8.4-2L1 will work on any Alpha; we did not test
against anything older than
XP1000's.
We cannot release any patches for any non-VSI version of VMS.
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
There is no 2L2 for the itanic ....
But, confusingly, there will be a 2L3 for Itanic but not for Alpha.
Dave Froble
2020-10-22 23:22:19 UTC
Permalink
Post by Craig A. Berry
Post by Dave Froble
Post by Arne Vajhøj
Post by Robert A. Brooks
Post by Phillip Helbig (undress to reply)
Post by Robert A. Brooks
Post by Chris Scheers
I think everyone is over thinking this.
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
V9.2 implies X86; we've already announced that we'll release patches
for V8.4-2Lx for Alpha and IA64, but only X86 will be V9.x
So I can run V8.4-2L1 on any Alpha (at least EV56 or better) and cluster
with 9.x if I have the patch?
We expect that V8.4-2L1 will work on any Alpha; we did not test
against anything older than
XP1000's.
We cannot release any patches for any non-VSI version of VMS.
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
There is no 2L2 for the itanic ....
But, confusingly, there will be a 2L3 for Itanic but not for Alpha.
They are out to destroy our minds. Quick, before it's too late, delete
the internet.

Oh, wait, it's already too late ....
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Camiel Vanderhoeven
2020-10-22 15:52:06 UTC
Permalink
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who happens to have a large collection of old computers, I ran V8.4-2L1 on most Alpha systems I have; including these older models:

- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1

Note that this isn't a test as in that I ran any kind of verification suite, I just installed the OS and played with it.

Camiel
Dave Froble
2020-10-22 21:18:19 UTC
Permalink
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
Note that this isn't a test as in that I ran any kind of verification suite, I just installed the OS and played with it.
Camiel
Wow! That's a bunch of old "junk" you got laying around. You got a
large warehouse?

I too have the same problem. Been cleaning stuff for 2 days now, and
barely started. Good thing I don't have as much as you do. Disks are
dying. Don't need an air cleaner, the systems running are great dust
collectors.

Trivia question, how much does an AlphaServer 800 weigh? Wasn't sure my
back was going to survive yesterday. Won't even try to lift the DS20.

DEC sure did believe in heavy gauge metal for the cases ....

And while on the subject of old "junk". My DS10L has 2 RJ45 network
ports. Only the "A" post is connected. DECnet keeps going up and down.
I seem to remember, maybe, using the "B" port and not having problems.
But it's been 10 years since it was last running. Anybody got any
ideas why this is happening?
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
John H. Reinhardt
2020-10-22 21:25:16 UTC
Permalink
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
Note that this isn't a test as in that I ran any kind of verification suite, I just installed the OS and played with it.
Camiel
Wow!  That's a bunch of old "junk" you got laying around.  You got a large warehouse?
Ha! Too bad you can't post pictures here. Camiel should post a picture of the "Wall of VAX" he did on the OpenVMS Facehbook page.
I too have the same problem.  Been cleaning stuff for 2 days now, and barely started.  Good thing I don't have as much as you do.  Disks are dying.  Don't need an air cleaner, the systems running are great dust collectors.
Trivia question, how much does an AlphaServer 800 weigh?  Wasn't sure my back was going to survive yesterday.  Won't even try to lift the DS20.
Not as heavy as an AlphaServer 1200.. Before I moved to Texas in 2017 I had two each of AlphaServer 800's and 1200's. Hauled them from one basemen to another when we moved 2 miles in 2005 but gave them away before moving 1000 miles to Texas. They are heavy.
DEC sure did believe in heavy gauge metal for the cases ....
And while on the subject of old "junk".  My DS10L has 2 RJ45 network ports.  Only the "A" post is connected.  DECnet keeps going up and down.  I seem to remember, maybe, using the "B" port and not having problems.  But it's been 10 years since it was last running.  Anybody got any ideas why this is happening?
Maybe just one going bad. The DS10 has the the same two ports and before switching to a DEGX2-TA card they both worked fine.
--
John H. Reinhardt
Bill Gunshannon
2020-10-23 00:20:29 UTC
Permalink
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test
against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1 on
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
Note that this isn't a test as in that I ran any kind of verification
suite, I just installed the OS and played with it.
Camiel
Wow!  That's a bunch of old "junk" you got laying around.  You got a
large warehouse?
I wish I still had a Multia. Actually, I wish I had a couple of them.
They were very nice Alpha boxes once you fixed the overheating problem.

bill
Camiel Vanderhoeven
2020-10-23 06:23:34 UTC
Permalink
Wow! That's a bunch of old "junk" you got laying around. You got a
large warehouse?
Moved to an old farm house six years ago. There are far more, and far larger systems in the collection: www.vaxbarn.com

Camiel
Hans Bachner
2020-10-22 21:42:23 UTC
Permalink
Hi Camiel,
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
[...]
an impressive list :-)

Where did you get the drivers from which are required for VMS on Multia?
I think the "compatibility kit" on the freeware CD contained a graphics
and a network driver, but only vor versions pre-dating V7.3.

Thanks & regards,
Hans.
Jan-Erik Söderholm
2020-10-22 21:52:25 UTC
Permalink
Post by Hans Bachner
Hi Camiel,
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against
anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1 on
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
[...]
an impressive list :-)
Where did you get the drivers from which are required for VMS on Multia? I
think the "compatibility kit" on the freeware CD contained a graphics and a
network driver, but only vor versions pre-dating V7.3.
Thanks & regards,
Hans.
Where *Camiel* get the drivers? :-)

Rmember that Camiel is one of the most "internal" programmers for VMS.
If there is a driver missing, he'll probably just write it... :-)
Dave Froble
2020-10-22 23:25:59 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Hans Bachner
Hi Camiel,
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test
against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
[...]
an impressive list :-)
Where did you get the drivers from which are required for VMS on
Multia? I think the "compatibility kit" on the freeware CD contained a
graphics and a network driver, but only vor versions pre-dating V7.3.
Thanks & regards,
Hans.
Where *Camiel* get the drivers? :-)
Rmember that Camiel is one of the most "internal" programmers for VMS.
If there is a driver missing, he'll probably just write it... :-)
Exactly what I thought as soon as I saw the question.

:-)
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Hans Bachner
2020-10-24 13:05:38 UTC
Permalink
Post by Dave Froble
Post by Jan-Erik Söderholm
Post by Hans Bachner
Hi Camiel,
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test
against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1
- DEC 3000 AXP (models 300, 400, and 800)
- DEC 4000 AXP
- AlphaServer 400, 500, 800, 1000, 1000A, 1200, 2100A, 4000, 8200
- AlphaStation 200, 250, 255
- Personal Workstation 600a
- Multia VX40
- Tadpole Alphabook 1
[...]
an impressive list :-)
Where did you get the drivers from which are required for VMS on
Multia? I think the "compatibility kit" on the freeware CD contained a
graphics and a network driver, but only vor versions pre-dating V7.3.
Thanks & regards,
Hans.
Where *Camiel* get the drivers? :-)
Rmember that Camiel is one of the most "internal" programmers for VMS.
If there is a driver missing, he'll probably just write it... :-)
Exactly what I thought as soon as I saw the question.
:-)
Both of you are right - I should have asked: where can *we* get the drivers?

:-)

Hans.

Phillip Helbig (undress to reply)
2020-10-22 16:31:52 UTC
Permalink
Post by Arne Vajhøj
older Alpha => run VSI 8.4-2L1
newer Alpha & Itanium => run VSI 8.4-2L2
This is getting confusing.

I'm pretty sure that 8.4-2L1 will run on older Alphas; at least on
XP1000s, but there is no obvious reason why it shouldn't run on older
hardware.

8.4-2L2 will run only on EV6 or better.

To cluster Alpha with x86, 8.4-2Lx requires a patch, but x could be 1 or
2.
Phillip Helbig (undress to reply)
2020-10-22 16:34:37 UTC
Permalink
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1 on
most Alpha systems I have; including these older models:

Very interesting. So the patch necessary for clustering x86 with Alpha
is also available for V8.4-2L1?
Jan-Erik Söderholm
2020-10-22 16:54:17 UTC
Permalink
Post by Camiel Vanderhoeven
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1 on
Very interesting. So the patch necessary for clustering x86 with Alpha
is also available for V8.4-2L1?
To cluster Alpha with x86, 8.4-2Lx requires a patch, but x
could be 1 or 2.
You can replace that "but" with "and", of course.
Phillip Helbig (undress to reply)
2020-10-22 18:06:36 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Very interesting. So the patch necessary for clustering x86 with Alpha
is also available for V8.4-2L1?
To cluster Alpha with x86, 8.4-2Lx requires a patch, but x
could be 1 or 2.
You can replace that "but" with "and", of course.
Right, but both were questions. :-)
Dave Froble
2020-10-22 21:20:44 UTC
Permalink
Post by Camiel Vanderhoeven
Post by Camiel Vanderhoeven
Post by Robert A. Brooks
We expect that V8.4-2L1 will work on any Alpha; we did not test against anything older than
XP1000's.
We, as VSI, did not test anything older, but as a private person who
happens to have a large collection of old computers, I ran V8.4-2L1 on
Very interesting. So the patch necessary for clustering x86 with Alpha
is also available for V8.4-2L1?
Ah, I think it's been written that such a patch will be required, and
available at some time. But for now, it may not even exist, so not yet
available.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Simon Clubley
2020-10-22 17:50:03 UTC
Permalink
Post by Robert A. Brooks
We cannot release any patches for any non-VSI version of VMS.
$ set response/mode=good_natured

You do know they are going to end up putting that phrase (or one of
your other variants) on your tombstone, right ? :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
Robert A. Brooks
2020-10-22 18:04:56 UTC
Permalink
Post by Simon Clubley
Post by Robert A. Brooks
We cannot release any patches for any non-VSI version of VMS.
$ set response/mode=good_natured
You do know they are going to end up putting that phrase (or one of
your other variants) on your tombstone, right ? :-)
I have a near-16 year old son. I'm used to be ignored.
--
-- Rob
Dave Froble
2020-10-22 21:23:21 UTC
Permalink
Post by Robert A. Brooks
Post by Simon Clubley
Post by Robert A. Brooks
We cannot release any patches for any non-VSI version of VMS.
$ set response/mode=good_natured
You do know they are going to end up putting that phrase (or one of
your other variants) on your tombstone, right ? :-)
I have a near-16 year old son. I'm used to be ignored.
But not by old farts who have learned to pay attention to important stuff.

:-)
--
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-22 14:38:59 UTC
Permalink
Post by Chris Scheers
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
Right, but it is related to clustering with x86 with Alpha.
Post by Chris Scheers
For a 9.2 node to cluster with a 8.4 node, the 8.4 node will need a
patch kit to update the cluster code.
8.4 is from HP. So VSI will deliver a patch for an HP VMS version?
Post by Chris Scheers
What I am waiting to see is for all SCS traffic to be encrypted. In
this case, the encryption certificate can replace the cluster password.
That is, if you have the certificate, you can join the cluster.
With all the other problems inherent in certificate maintenance? :-|
Jan-Erik Söderholm
2020-10-22 16:05:49 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Chris Scheers
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
Right, but it is related to clustering with x86 with Alpha.
Post by Chris Scheers
For a 9.2 node to cluster with a 8.4 node, the 8.4 node will need a
patch kit to update the cluster code.
8.4 is from HP. So VSI will deliver a patch for an HP VMS version?
Was it really *that* unclear that, in this specific case, "8.4" refers
to any 8.4 release from *VSI*?
Phillip Helbig (undress to reply)
2020-10-22 16:32:39 UTC
Permalink
Post by Jan-Erik Söderholm
Post by Phillip Helbig (undress to reply)
Post by Chris Scheers
From what has been said, it seems that this is NOT an x86 issue.
It is a VMS 9.2 issue.
Right, but it is related to clustering with x86 with Alpha.
Post by Chris Scheers
For a 9.2 node to cluster with a 8.4 node, the 8.4 node will need a
patch kit to update the cluster code.
8.4 is from HP. So VSI will deliver a patch for an HP VMS version?
Was it really *that* unclear that, in this specific case, "8.4" refers
to any 8.4 release from *VSI*?
Yes. I'm tired. :-|
Chris Scheers
2020-10-22 18:40:22 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Chris Scheers
For a 9.2 node to cluster with a 8.4 node, the 8.4 node will need a
patch kit to update the cluster code.
8.4 is from HP. So VSI will deliver a patch for an HP VMS version?
Well, I thought it was obvious that I meant the 8.4 from VSI.

However, if you reread my statement, it still holds true for HPE 8.4.

To cluster it with 9.2, you would need a patch kit.

I never said that VSI would deliver such a patch.

<grin>
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Chris Scheers
2020-10-22 19:16:36 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Chris Scheers
What I am waiting to see is for all SCS traffic to be encrypted. In
this case, the encryption certificate can replace the cluster password.
That is, if you have the certificate, you can join the cluster.
With all the other problems inherent in certificate maintenance? :-|
While the issues of certificate management are something that should
really be handled by VMS, that has nothing to do with what I am
suggesting here.

How much maintenance do you do of your cluster passwords?

A certificate used to encrypt SCS communications is NOT something that
you would want changing at random times. Nor should it require access
to the internet. It would be a fairly static datum.
--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ***@applied-synergy.com
Fax: 817-237-3074
Stephen Hoffman
2020-10-22 22:53:50 UTC
Permalink
Post by Dave Froble
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.

This was seemingly documented nowhere, save by its omission.

This limitation was known to VSI Support.

Hopefully, that documentation been remedied.

New VSI OpenVMS Alpha installations also ended up paying more than
upgrades. Though that's all using SaaS / subscription pricing now.

But yes, there are differences between OpenVMS Alpha V8.4-2L1 and
OpenVMS Alpha V8.4-2L2 beyond the compilation differences.

VSI OpenVMS I64 V8.4-2L1 can be installed, and can be an upgrade.

Past the OpenVMS I64 V8.4-2L3 update / roll-up / remaster, I wouldn't
expect to see more than maintenance on Alpha and Itanium.
--
Pure Personal Opinion | HoffmanLabs LLC
John H. Reinhardt
2020-10-22 23:14:15 UTC
Permalink
Post by Stephen Hoffman
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.
If you ignore the two errors on a fresh install, it appears to install okay. Perhaps some related error will turn up, but so far in a month of use, nothing has reared it's head yet.

Execution phase starting ...

The following products will be installed to destinations:
VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1 DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS CDSA V2.4-320A DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS DECNET_PHASE_IV V8.4-2L1 DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS DWMOTIF V1.7-F DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1 DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS HPBINARYCHECKER V1.1-A DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS KERBEROS V3.1-152A DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS OPENVMS V8.4-2L1 DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS SSL V1.4-502A DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS SSL1 V1.0-2JA DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS TCPIP V5.7-13ECO5F DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS TDC_RT V2.3-1220 DISK$CLARKE084:[VMS$COMMON.]
VSI AXPVMS VMS V8.4-2L1 DISK$CLARKE084:[VMS$COMMON.]

Portion done: 0%...10%

%PCSI-E-OPENOUT, error opening DISK$CLARKE084:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; as output
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no

%PCSI-E-OPENIN, error opening DISK$CLARKE084:[VMS$COMMON.][SYSLIB]DCLTABLES.EXE; as input
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no
Portion done: 20%...30%...40%...50%...60%...70%...80%...90%
%PCSI-I-PRCOUTPUT, output from subprocess follows ...
% - Execute SYS$MANAGER:TCPIP$CONFIG.COM to proceed with configuration of
% HP TCP/IP Services for OpenVMS.
%
Portion done: 100%

The following products have been installed:
VSI AXPVMS AVAIL_MAN_BASE V8.4-2L1 Layered Product
VSI AXPVMS CDSA V2.4-320A Layered Product
VSI AXPVMS DECNET_PHASE_IV V8.4-2L1 Layered Product
VSI AXPVMS DWMOTIF V1.7-F Layered Product
VSI AXPVMS DWMOTIF_SUPPORT V8.4-2L1 Layered Product
VSI AXPVMS HPBINARYCHECKER V1.1-A Layered Product
VSI AXPVMS KERBEROS V3.1-152A Layered Product
VSI AXPVMS OPENVMS V8.4-2L1 Platform (product suite)
VSI AXPVMS SSL V1.4-502A Layered Product
VSI AXPVMS SSL1 V1.0-2JA Layered Product
VSI AXPVMS TCPIP V5.7-13ECO5F Layered Product
VSI AXPVMS TDC_RT V2.3-1220 Layered Product
VSI AXPVMS VMS V8.4-2L1 Operating System
Post by Stephen Hoffman
This was seemingly documented nowhere, save by its omission.
It was mentioned here, I think, when the release was announced. Once reminded, I remembered seeing it at least.
Post by Stephen Hoffman
This limitation was known to VSI Support.
Hopefully, that documentation been remedied.
New VSI OpenVMS Alpha installations also ended up paying more than upgrades. Though that's all using SaaS / subscription pricing now.
But yes, there are differences between OpenVMS Alpha V8.4-2L1 and OpenVMS Alpha V8.4-2L2 beyond the compilation differences.
VSI OpenVMS I64 V8.4-2L1 can be installed, and can be an upgrade.
Past the OpenVMS I64 V8.4-2L3 update / roll-up / remaster, I wouldn't expect to see more than maintenance on Alpha and Itanium.
--
John H. Reinhardt
Phillip Helbig (undress to reply)
2020-10-23 08:49:16 UTC
Permalink
Post by John H. Reinhardt
%PCSI-E-OPENOUT, error opening DISK$CLARKE084:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; as output
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no
%PCSI-E-OPENIN, error opening DISK$CLARKE084:[VMS$COMMON.][SYSLIB]DCLTABLES.EXE; as input
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no
To me, HELP and DCL are pretty important. Really no ill effects?
Jan-Erik Söderholm
2020-10-23 10:47:15 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by John H. Reinhardt
%PCSI-E-OPENOUT, error opening DISK$CLARKE084:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; as output
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no
%PCSI-E-OPENIN, error opening DISK$CLARKE084:[VMS$COMMON.][SYSLIB]DCLTABLES.EXE; as input
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] no
To me, HELP and DCL are pretty important. Really no ill effects?
That must be highly dependent on what the next step was efter the
steps that created those errors. Maybe some "update if exists, create
if not". And the "Terminating is strongly recommended" message might be
a generic processing for any error and not specific for these two errors.

Maybe just a missing check for file existance before the operation
that failed. And HELP and DCL obviously works for John Reinhardt, not?
John H. Reinhardt
2020-10-23 14:33:38 UTC
Permalink
Post by Jan-Erik Söderholm
Post by John H. Reinhardt
%PCSI-E-OPENOUT, error opening DISK$CLARKE084:[VMS$COMMON.][SYSHLP]HELPLIB.HLB; as output
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended.  Do you want to terminate? [YES] no
%PCSI-E-OPENIN, error opening DISK$CLARKE084:[VMS$COMMON.][SYSLIB]DCLTABLES.EXE; as input
-RMS-E-FNF, file not found
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended.  Do you want to terminate? [YES] no
To me, HELP and DCL are pretty important.  Really no ill effects?
That must be highly dependent on what the next step was efter the
steps that created those errors. Maybe some "update if exists, create
if not". And the "Terminating is strongly recommended" message might be
a generic processing for any error and not specific for these two errors.
Maybe just a missing check for file existance before the operation
that failed. And HELP and DCL obviously works for John Reinhardt, not?
None seen so far. There's no indication what was being installed at that point, but HELPLIB.HLB and DCLTABLES.EXE definitely get installed at some point.

$ dir sys$help:helplib.hlb

Directory SYS$COMMON:[SYSHLP]

HELPLIB.HLB;1 12001/12003 5-SEP-2020 02:09:58.68 [SYSTEM] (RWED,RWED,RE,RE)

Total of 1 file, 12001/12003 blocks.
$
$ dir sys$library:dcltables.exe

Directory SYS$COMMON:[SYSLIB]

DCLTABLES.EXE;78 846/846 5-SEP-2020 02:10:07.40 [SYSTEM] (RWED,RWED,RE,RE)

Total of 1 file, 846/846 blocks.
--
John H. Reinhardt
Phillip Helbig (undress to reply)
2020-10-23 08:47:59 UTC
Permalink
Post by Stephen Hoffman
Post by Dave Froble
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.
Post by Stephen Hoffman
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. :-)
Hans Bachner
2020-10-20 14:00:40 UTC
Permalink
Post by Phillip Helbig (undress to reply)
Post by Chris Townley
"After analyzing the feedback given by the participants of the Community
License program, VMS Software has made the decision to remove the
limitations imposed by the previous version of the license.
Great! Well done!
Post by Chris Townley
This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system
As far as the number of units go, yes, but presumably the VSI license
makes sense only with VSI VMS and the latter requires a reasonably new
CPU, right? At least EV6/21264?
This depends on the definition of "requires".

The QuickSpecs of V8.4-2L1
(<https://vmssoftware.com/pdfs/vms_pdf/VSI_OVMS_Alpha_V842L1_SPD_QS.pdf>)
mention only DS/ES systems (except the ES80) as "Supported". QuickSpecs
for V8.4-2L2 also include the ES80 and the GS80/160/320/1280 systems
"pending completion of testing".

Having said that, I can successfully run V8.4-2L1 on a CHARON-AXP
Post by Phillip Helbig (undress to reply)
VSICL1> sho sys /full /noproc
OpenVMS V8.4-2L1 on node VSICL1 20-OCT-2020 15:51:55.87 Uptime 0 00:07:48
AlphaStation 400 4/166
VSICL1>
I don't have the time right now to pull one ot the really old Alphas off
the shelf and install VSI VMS on it. But CHARON does a quite good job on
emulating the various EVn architectures. E.g. the above configuration
won't boot V8.4-2L2 (like the real hardware).
Post by Phillip Helbig (undress to reply)
Post by Chris Townley
and the Integrity license will include HBVS
and clustering until further notice.
In fact, it includes the HAOE license.

Hans.
Bill Gunshannon
2020-10-20 13:41:28 UTC
Permalink
Post by Chris Townley
"After analyzing the feedback given by the participants of the Community
License program, VMS Software has made the decision to remove the
limitations imposed by the previous version of the license.
This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system and the Integrity license will include HBVS
and clustering until further notice. However, the Community License
Agreement remains unchanged, so any commercial use of the operating
system is strictly forbidden and those who are interested in commercial
scenarios are eligible to a common or ISV license that can be agreed
with the sales department."
New alpha PAK was attached
I got an email, too. But no PAKs attached. Told me to go back to their
site and get them. I will try to do that a bit later.

bill
Chris Townley
2020-10-20 13:55:30 UTC
Permalink
Post by Chris Townley
"After analyzing the feedback given by the participants of the
Community License program, VMS Software has made the decision to
remove the limitations imposed by the previous version of the license.
This means that from now on, the number of units in the PAK for Alpha
will be unlimited thus making it possible to install the community
license on any Alpha system and the Integrity license will include
HBVS and clustering until further notice. However, the Community
License Agreement remains unchanged, so any commercial use of the
operating system is strictly forbidden and those who are interested in
commercial scenarios are eligible to a common or ISV license that can
be agreed with the sales department."
New alpha PAK was attached
I got an email, too.  But no PAKs attached.  Told me to go back to their
site and get them.  I will try to do that a bit later.
bill
Yes, not attached, but a link that just downloaded them

Chris
Loading...