New VSI Community license PAK

[Chris Townley]

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]

Chris Townley schrieb am 20.10.2020 um 11:51:
> 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, [...]"

>
> New alpha PAK was attached
>
> Sounds good
>
> Chris

Great news, indeed. I also received this email just minutes ago.

Thanks for listening, VSI!

Hans.

[Phillip Helbig (undress to reply)]

In article <rmmbui$k67$1...@dont-email.me>, Chris Townley

<ne...@cct-net.co.uk> writes:

> "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!

> 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?

> and the Integrity license will include HBVS
> and clustering until further notice.

Great!

> 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.

[Jairo Alves]

nice

[Chris Townley]

On 20/10/2020 13:08, Phillip Helbig (undress to reply) wrote:

>
> 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

[Bill Gunshannon]

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

[Arne Vajhøj]

On 10/20/2020 6:31 AM, Hans Bachner wrote:
> Chris Townley schrieb am 20.10.2020 um 11:51:
>> 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, [...]"
>>
>> 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

[Chris Townley]

Yes, not attached, but a link that just downloaded them

Chris

[Hans Bachner]

Phillip Helbig (undress to reply) schrieb am 20.10.2020 um 14:08:
> In article <rmmbui$k67$1...@dont-email.me>, Chris Townley
> <ne...@cct-net.co.uk> writes:
>
>> "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!
>
>> 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
AlphaStation 400:

> 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).

>> and the Integrity license will include HBVS
>> and clustering until further notice.

In fact, it includes the HAOE license.

Hans.

[Hans Bachner]

Yes, but... it seems that FreeAXP is cheating a bit, as a FreeAXP
emulated AlphaServer 400 also runs V8.4-2L2:

> 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)]

In article <rmml00$jp4$1...@dont-email.me>, Chris Townley

Maybe the EV6 requirement was for the version of Alpha which will
cluster with x86.

[Dave Froble]

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: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Phillip Helbig (undress to reply)]

In article <rmn6v2$sci$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> > 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]

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)]

In article <rmna5j$mg6$1...@dont-email.me>, "John H. Reinhardt"

<johnhre...@thereinhardts.org> writes:

> 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]

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)]

In article <rmneg4$luc$1...@dont-email.me>, "Robert A. Brooks"

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]

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]

>
> 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]

Per the note from Robert Brooks, 8.4-2lx with patches will be required to

[Robert A. Brooks]

+1

--

-- Rob

[Dave Froble]

On 10/20/2020 1:37 PM, Phillip Helbig (undress to reply) wrote:
> In article <rmn6v2$sci$1...@dont-email.me>, Dave Froble
> <da...@tsoft-inc.com> writes:
>
>>> 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.

> 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.

> 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 ....

> 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.

> 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.

[Dave Froble]

No, and, it won't work anyway if the cluster interconnect stuff is changed.

[Dave Froble]

Let me guess, Steve's harping on security, right?

[Dave Froble]

On 10/20/2020 5:19 PM, Phillip Helbig (undress to reply) wrote:
> In article <rmneg4$luc$1...@dont-email.me>, "Robert A. Brooks"
> <FIRST...@vmssoftware.com> writes:
>
>> On 10/20/2020 3:25 PM, Phillip Helbig (undress to reply) wrote:
>>> In article <rmna5j$mg6$1...@dont-email.me>, "John H. Reinhardt"
>>> <johnhre...@thereinhardts.org> writes:
>>>
>>>> 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.

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.

[Dave Froble]

No, Robert used "2Lx", which I take to be both 2L1 and 2L2.

[Phillip Helbig (undress to reply)]

In article <rmntem$ldn$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> 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)]

In article <rmntrb$ng1$1...@dont-email.me>, Dave Froble

<da...@tsoft-inc.com> writes:

> > 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.

> 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]

Which responses?

Hans.

[Phillip Helbig (undress to reply)]

In article <rmofvl$br7$1...@gioia.aioe.org>,
hel...@asclothestro.multivax.de (Phillip Helbig (undress to reply))
writes:

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.

[abrsvc]

You are correct and I misread the note. It would appear that both variants will be patched as you (and Robert) indicated. My error.

[Simon Clubley]

On 2020-10-20, Dave Froble <da...@tsoft-inc.com> wrote:
> On 10/20/2020 3:40 PM, Robert A. Brooks wrote:
>>
>> 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, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

[Dave Froble]

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.

[Dave Froble]

I don't recall any "valid" responses that indicate that. Yes, a
mistake, but later corrected.

[abrsvc]

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]

Den 2020-10-21 kl. 15:57, skrev Dave Froble:
> On 10/21/2020 6:28 AM, abrsvc wrote:
>> On Tuesday, 20 October 2020 20:04:38 UTC-4, Dave Froble  wrote:
>>> On 10/20/2020 6:02 PM, abrsvc wrote:
>>>>>
>>>>> 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: da...@tsoft-inc.com
>>> 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.

[Stephen Hoffman]

On 2020-10-20 23:59:22 +0000, Dave Froble said:

> On 10/20/2020 3:40 PM, Robert A. Brooks wrote:
>>
>> 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

[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.

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.

-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

[Robert A. Brooks]

On 10/21/2020 4:52 PM, Chris Scheers wrote:
> 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]

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]

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.

[Simon Clubley]

On 2020-10-21, Stephen Hoffman <seao...@hoffmanlabs.invalid> wrote:
> On 2020-10-20 23:59:22 +0000, Dave Froble said:
>>
>> 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.

>
> 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.

[Phillip Helbig (undress to reply)]

In article <rmq72s$82e$1...@dont-email.me>, Chris Scheers

<ch...@applied-synergy.com> writes:

> 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.

> 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?

> 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? :-|

[Phillip Helbig (undress to reply)]

In article <rmq7k3$b3a$1...@dont-email.me>, "Robert A. Brooks"

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?

[Phillip Helbig (undress to reply)]

In article <rmrtn2$no5$1...@dont-email.me>, Simon Clubley

<clubley@remove_me.eisner.decus.org-Earth.UFP> writes:

> 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. :-)

[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 cannot release any patches for any non-VSI version of VMS.

--

-- Rob

[Arne Vajhøj]

So the short version is:

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

?

Arne

[Camiel Vanderhoeven]

Op donderdag 22 oktober 2020 om 17:33:29 UTC+2 schreef 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

[Craig A. Berry]

On 10/22/20 10:47 AM, Arne Vajhøj wrote:

> So the short version is:
>
> 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]

So:

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

[Jan-Erik Söderholm]

Den 2020-10-22 kl. 16:38, skrev Phillip Helbig (undress to reply):
> In article <rmq72s$82e$1...@dont-email.me>, Chris Scheers
> <ch...@applied-synergy.com> writes:
>
>> 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.
>
>> 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*?

[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).

[Phillip Helbig (undress to reply)]

In article <rms9j3$18dh$1...@gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?=

<ar...@vajhoej.dk> writes:

> 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)]

In article <rmsaku$jnp$2...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

Yes. I'm tired. :-|

[Phillip Helbig (undress to reply)]

In article <00bee733-c48f-4059...@googlegroups.com>,

Camiel Vanderhoeven <iamc...@gmail.com> writes:

> Op donderdag 22 oktober 2020 om 17:33:29 UTC+2 schreef 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]

Right. You said that yourself in your post just 3 min ago:

> 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.

[Simon Clubley]

On 2020-10-22, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>
> 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 ? :-)

[John H. Reinhardt]

On 10/22/2020 11:30 AM, Craig A. Berry wrote:
>
> 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

[Simon Clubley]

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

[Robert A. Brooks]

On 10/22/2020 1:50 PM, Simon Clubley wrote:
> On 2020-10-22, Robert A. Brooks <FIRST...@vmssoftware.com> wrote:
>>
>> 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

[Phillip Helbig (undress to reply)]

In article <rmsdfq$jnp$3...@dont-email.me>,
=?UTF-8?Q?Jan-Erik_S=c3=b6derholm?= <jan-erik....@telia.com>
writes:

> > Very interesting. So the patch necessary for clustering x86 with Alpha
> > is also available for V8.4-2L1?
> >
>

> Right. You said that yourself in your post just 3 min ago:
>
> > 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. :-)

[Chris Scheers]

Phillip Helbig (undress to reply) wrote:

> In article <rmq72s$82e$1...@dont-email.me>, 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]

Phillip Helbig (undress to reply) wrote:

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.

[Dave Froble]

There is no 2L2 for the itanic ....

:-)


--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Craig A. Berry]

On 10/22/20 4:03 PM, Dave Froble wrote:
> On 10/22/2020 11:47 AM, Arne Vajhøj wrote:
>> On 10/22/2020 11:33 AM, Robert A. Brooks wrote:
>>> On 10/22/2020 10:39 AM, Phillip Helbig (undress to reply) wrote:
>>>> In article <rmq7k3$b3a$1...@dont-email.me>, "Robert A. Brooks"
>>>> <FIRST...@vmssoftware.com> writes:
>>>>> On 10/21/2020 4:52 PM, Chris Scheers wrote:
>>>>>> 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
>
> There is no 2L2 for the itanic ....

But, confusingly, there will be a 2L3 for Itanic but not for Alpha.

[Dave Froble]

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.

[Jan-Erik Söderholm]

Den 2020-10-22 kl. 23:06, skrev Dave Froble:
> On 10/22/2020 12:04 PM, Jan-Erik Söderholm wrote:
>> Den 2020-10-22 kl. 17:59, skrev Craig A. Berry:
>>>
>>> On 10/22/20 10:47 AM, Arne Vajhøj wrote:
>>>
>>>> So the short version is:
>>>>
>>>> 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
>
> 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]

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?

[Dave Froble]

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.

[Dave Froble]

But not by old farts who have learned to pay attention to important stuff.

:-)

[John H. Reinhardt]

On 10/22/2020 4:18 PM, Dave Froble wrote:
> On 10/22/2020 11:52 AM, Camiel Vanderhoeven wrote:
>> Op donderdag 22 oktober 2020 om 17:33:29 UTC+2 schreef 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
>>
>
> 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

[Hans Bachner]

Hi Camiel,

Camiel Vanderhoeven schrieb am 22.10.2020 um 17:52:
> Op donderdag 22 oktober 2020 om 17:33:29 UTC+2 schreef 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
>

> [...]

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]

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... :-)

[Stephen Hoffman]

On 2020-10-20 23:56:29 +0000, Dave Froble said:

> 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]

On 10/22/2020 5:53 PM, Stephen Hoffman wrote:
> On 2020-10-20 23:56:29 +0000, Dave Froble said:
>
>> 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

> 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.

> 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

[Dave Froble]

They are out to destroy our minds. Quick, before it's too late, delete
the internet.

Oh, wait, it's already too late ....

[Dave Froble]

Exactly what I thought as soon as I saw the question.

:-)

[Bill Gunshannon]

On 10/22/20 5:18 PM, Dave Froble wrote:
> On 10/22/2020 11:52 AM, Camiel Vanderhoeven wrote:
>> Op donderdag 22 oktober 2020 om 17:33:29 UTC+2 schreef 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
>>
>
> 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]

Op donderdag 22 oktober 2020 om 23:18:26 UTC+2 schreef Dave Froble:

> 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

[Phillip Helbig (undress to reply)]

In article <rmt2hu$ooi$1...@dont-email.me>, Stephen Hoffman

<seao...@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. :-)

[Phillip Helbig (undress to reply)]

In article <rmt3o7$v90$1...@dont-email.me>, "John H. Reinhardt"

<johnhre...@thereinhardts.org> writes:

> %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]

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]

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

[Craig A. Berry]

On 10/22/20 12:58 PM, Simon Clubley wrote:
> On 2020-10-22, Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:
>> In article <rmrtn2$no5$1...@dont-email.me>, Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>> 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

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)]

In article <rmvfrc$hcb$1...@dont-email.me>, "Craig A. Berry"

<craig...@nospam.mac.com> writes:

> 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>

At least it's a better name than Turbo Laser. :-)

[Scott Dorsey]

Phillip Helbig (undress to reply) <hel...@asclothestro.multivax.de> wrote:

That was just an upgraded Dodge Daytona.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Hans Bachner]

Both of you are right - I should have asked: where can *we* get the drivers?

:-)

Hans.