VAX VMS going forward

[Alice Wyan]

If I understand the situation correctly, HPE is completely dropping support for VAX VMS, but the rights haven't been transferred to VSI. This means starting next year VMS on the VAX is essentially abandoned.

If HPE is no longer going to be making money out of it, what would be stopping them from selling it/give the rights away to, say, a hobbyist collective that could be set up to preserve this system? I guess there'd be quite a legal mess of rights behind the old code, but... would it be a doable thing? What sort of money could we be talking about to get this sort of transfer done?

[Scott Dorsey]

If I understand the situation correctly, HPE is completely dropping support=
for VAX VMS, but the rights haven't been transferred to VSI. This means st=
arting next year VMS on the VAX is essentially abandoned.

Yes.

If HPE is no longer going to be making money out of it, what would be stopp=
ing them from selling it/give the rights away to, say, a hobbyist collectiv=
e that could be set up to preserve this system? I guess there'd be quite a =
legal mess of rights behind the old code, but... would it be a doable thing=
? What sort of money could we be talking about to get this sort of transfer=
done?

Nobody knows. Nobody even has a clue. Write a paper letter to HPE's legal
department and ask.
--scott

[Simon Clubley]

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping support
for VAX VMS, but the rights haven't been transferred to VSI. This means
starting next year VMS on the VAX is essentially abandoned.

HPE dropped support for VAX/VMS a long time ago, but continued to issue
hobbyist licences for it.

What is new is that HPE are no longer issuing hobbyist licences, including
those for VAX/VMS. (That should have been at the end of this year, but it
appears to have happened already.)

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system? I guess there'd be
quite a legal mess of rights behind the old code, but... would it be a doable
thing? What sort of money could we be talking about to get this sort of
transfer done?

The "legal mess" is one of the reasons why this is unlikely to happen.

Do HPE even still have people available with enough VAX/VMS knowledge
to navigate the "legal mess" from their side of this ?

HPE are also unlikely to sell it or give the rights away for various
other reasons. At best you might get them to licence the rights to
someone else as they did with VSI for Alpha/Itanium/x86-64 and DEC
did with Mentec for the PDP-11.

The most viable course of action (but still extremely unlikely) is for
HPE to maintain all control over VAX/VMS but to issue a final set of
non-terminating licences. That is also unlikely because there is no
motivation for HPE to invest the time, resources and legal costs in
investigating this option.

Simon.

[Phillip Helbig (undress to reply)]

Post by Simon Clubley
The most viable course of action (but still extremely unlikely) is for
HPE to maintain all control over VAX/VMS but to issue a final set of
non-terminating licences. That is also unlikely because there is no
motivation for HPE to invest the time, resources and legal costs in
investigating this option.

I don't know how much it would cost. Someone could collect money from
those interested, say, $500 per person, and when a substantial sum comes
together, ask HPE if they are interested. If they say that it will cost
more, then get more people to pay in and/or get them to pay more.

[John Dallman]

Post by Phillip Helbig (undress to reply)
I don't know how much it would cost. Someone could collect money
from those interested, say, $500 per person, and when a substantial
sum comes together, ask HPE if they are interested. If they say
that it will cost more, then get more people to pay in and/or get
them to pay more.

Do you think you can get 200 people to pony up $500 each? I think that's
the minimum you'd need to have any chance of interesting HPE in doing the
legal work. Their lawyers have plenty to do.

John

[Phillip Helbig (undress to reply)]

Post by John Dallman

Post by Phillip Helbig (undress to reply)
I don't know how much it would cost. Someone could collect money
from those interested, say, $500 per person, and when a substantial
sum comes together, ask HPE if they are interested. If they say
that it will cost more, then get more people to pay in and/or get
them to pay more.

Do you think you can get 200 people to pony up $500 each? I think that's
the minimum you'd need to have any chance of interesting HPE in doing the
legal work. Their lawyers have plenty to do.

I don't plan on doing it, but I don't think that that is completely
unrealistic. I'm sure that there are a couple of hundred people still
running VAXen as a hobby, and $500 is probably less than they pay for a
year of electricity for them.

Of course, someone would have to organize this, goto HPE and offer
$100,000 in return for the production of such a license, and if they say
no then refund at least almost all of the money. Would such a license
be only for those who paid? If so, could they sell them? If there is
just one license, could the consortium make it available to others? For
a fee? There would be many details to work out.

[Alice Wyan]

Post by Phillip Helbig (undress to reply)
Of course, someone would have to organize this, goto HPE and offer
$100,000 in return for the production of such a license, and if they say
no then refund at least almost all of the money. Would such a license
be only for those who paid? If so, could they sell them? If there is
just one license, could the consortium make it available to others? For
a fee? There would be many details to work out.

It would be quite a complicated endeavour. I'm assuming HPE wouldn't even cover lawyer costs for $100k, whereas on the hobbyist side $100k is for the most part a ridiculously high number to administer...

[John Dallman]

Post by Alice Wyan
It would be quite a complicated endeavour. I'm assuming HPE
wouldn't even cover lawyer costs for $100k, whereas on the hobbyist
side $100k is for the most part a ridiculously high number to
administer...

The lawyer work would be the problem. HPE would be giving away IP that is
closely related to stuff they get money for, and lawyers smell
shareholder lawsuits rather readily near that concept.

John

[Don North]

Post by John Dallman

Post by Alice Wyan
It would be quite a complicated endeavour. I'm assuming HPE
wouldn't even cover lawyer costs for $100k, whereas on the hobbyist
side $100k is for the most part a ridiculously high number to
administer...

The lawyer work would be the problem. HPE would be giving away IP that is
closely related to stuff they get money for, and lawyers smell
shareholder lawsuits rather readily near that concept.
John

If there is really anything of value left, HPE should find some group
or organization to donate the IP to, and take a big tax donation.

[Arne Vajhøj]

Post by Phillip Helbig (undress to reply)

Post by John Dallman

Post by Phillip Helbig (undress to reply)
I don't know how much it would cost. Someone could collect money
from those interested, say, $500 per person, and when a substantial
sum comes together, ask HPE if they are interested. If they say
that it will cost more, then get more people to pay in and/or get
them to pay more.

Do you think you can get 200 people to pony up $500 each? I think that's
the minimum you'd need to have any chance of interesting HPE in doing the
legal work. Their lawyers have plenty to do.

I don't plan on doing it, but I don't think that that is completely
unrealistic. I'm sure that there are a couple of hundred people still
running VAXen as a hobby, and $500 is probably less than they pay for a
year of electricity for them.
Of course, someone would have to organize this, goto HPE and offer
$100,000 in return for the production of such a license, and if they say
no then refund at least almost all of the money. Would such a license
be only for those who paid? If so, could they sell them? If there is
just one license, could the consortium make it available to others? For
a fee? There would be many details to work out.

Finding 200 x $500 may be tough but are not totally unrealistic.

But I doubt that HPE will be interested.

HPE is a XX B$ company. 100 K$ is nothing for HPE.

I suspect that you can't get the attention of anyone with
real power within HPE for less than 10 M$.

But OK - I don't know anything about how HPE works internally - I
could be totally wrong.

Arne

[John E. Malmberg]

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

As I understand it, VSI only has the rights to distribute and license
software binaries that they have built and tested.

This does not restrict them from producing a VAX release, but they do
not have the resources add a VAX build to their backlog of work.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a
hobbyist collective that could be set up to preserve this system? I
guess there'd be quite a legal mess of rights behind the old code,
but... would it be a doable thing? What sort of money could we be
talking about to get this sort of transfer done?

From OpenVMS Customer Lab Special Notification:

"Users who wish to avail of HPE OpenVMS long term licenses are
encouraged to purchase permanent licenses at standard prices. You may
contact [Fellman, Jon] <jon.fellman at hpe.com> for the same."

I do not know what the current standard prices are for a license.

The price may still vary based on the size of the system.
And license are needed for every Layered Product or SIP that are used.

If someone knows those prices and are not restricted from posting them,
it might be nice to see them.

I do not know how long that offer is valid for either.

As far as contacting HPE at a level that could make that decision, I
have no idea where to start. If you own any HPE stock, you can make a
stock-holder's request for the board to vote on at the next election.

The OpenVMS hobbyist program was created at a time where the executives
of the company actually attended events where their customers of all
sizes could meet with them. That is not happening any more.

I think I am going to try NetBSD/VAX out.

I also just discovered that the SimH/VAX project supports building
infoservers and the infoserver license software and keys are on the
OpenVMS freeware disks.

Regards,
-John

[Phillip Helbig (undress to reply)]

Post by John E. Malmberg

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

As I understand it, VSI only has the rights to distribute and license
software binaries that they have built and tested.

That could change, theoretically.

Post by John E. Malmberg
I think I am going to try NetBSD/VAX out.

What sort of license does that have?

[Simon Clubley]

Post by Phillip Helbig (undress to reply)

Post by John E. Malmberg
I think I am going to try NetBSD/VAX out.

What sort of license does that have?

Standard BSD style licence for the stuff written by the NetBSD people
themselves and a mixture of the usual licences for the other packages
in the distribution.

Simon.

[Bob Eager]

On Fri, 17 Jul 2020 16:45:30 +0000, Phillip Helbig (undress to reply)

Post by Phillip Helbig (undress to reply)

Post by John E. Malmberg

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

As I understand it, VSI only has the rights to distribute and license
software binaries that they have built and tested.

That could change, theoretically.

Post by John E. Malmberg
I think I am going to try NetBSD/VAX out.

What sort of license does that have?

Probably a BSD licence. Which is very free, in both senses.

[Bill Gunshannon]

Post by Phillip Helbig (undress to reply)

Post by John E. Malmberg

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

As I understand it, VSI only has the rights to distribute and license
software binaries that they have built and tested.

That could change, theoretically.

Post by John E. Malmberg
I think I am going to try NetBSD/VAX out.

What sort of license does that have?

That's a silly question. A BSD License, naturally.
It's free, much freer than Linux.

bill

[Alexander Schreiber]

Post by Phillip Helbig (undress to reply)

Post by John E. Malmberg

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

As I understand it, VSI only has the rights to distribute and license
software binaries that they have built and tested.

That could change, theoretically.

Post by John E. Malmberg
I think I am going to try NetBSD/VAX out.

What sort of license does that have?

It's partially in the name - it's one of the OpenSource BSD OSes, so it
has a BSD license, specifically the "2 clause" Berkely-style license
(TLDR: Free to use, if redistributing tell people where you got it from,
keep the copyright notice intact), details here:
https://www.netbsd.org/about/redistribution.html

Also, of course, comes with _complete_ system sources.

So, no payment required, but donations of any size appreciated ;-)

Kind regards,
Alex.

[Dave Froble]

Post by John E. Malmberg
"Users who wish to avail of HPE OpenVMS long term licenses are
encouraged to purchase permanent licenses at standard prices. You may
contact [Fellman, Jon] <jon.fellman at hpe.com> for the same."

Well, I did ask.

---
Do you just need VMS base?


Thank you,


Jon Fellman
Product Manager
Hewlett-Packard Financial Services
C#508-250-3676
Skype#508-467-0134
FX#978-474-2665
---

Notice where he works ...

I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.

So far I have not heard back.

Post by John E. Malmberg
I do not know what the current standard prices are for a license.
The price may still vary based on the size of the system.
And license are needed for every Layered Product or SIP that are used.
If someone knows those prices and are not restricted from posting them,
it might be nice to see them.
I do not know how long that offer is valid for either.

If I ever get that info, I'll post it here.

Post by John E. Malmberg
As far as contacting HPE at a level that could make that decision, I
have no idea where to start. If you own any HPE stock, you can make a
stock-holder's request for the board to vote on at the next election.

Now, this is the best idea I've heard yet. Mention the past hobbyist
program(s), that HPe has no forthcoming revenue from VAX/VMS, and the
"goodness" of promoting historical things.

Find someone with stock, or, purchase a share. Who knows, might even
make some money when selling it.

[Robert A. Brooks]

Post by Dave Froble
Notice where he works ...
I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.
So far I have not heard back.

Give him a call; those cell and skype area codes are in MA.

[Phillip Helbig (undress to reply)]

Post by Dave Froble
Jon Fellman
Product Manager
Hewlett-Packard Financial Services
C#508-250-3676
Skype#508-467-0134
FX#978-474-2665
---
Notice where he works ...

Remember The Hitchhiker's Guide to VMS and the explanation for why the
default prompt is the dollar sign? :-)

[Alice Wyan]

Post by Dave Froble
I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.

I was quoted $500 for VMS and $500 for TCP/IP, so I guess that might be their flat fee quote for any of the PAKs...

[Phillip Helbig (undress to reply)]

Post by Alice Wyan

Post by Dave Froble
I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.

I was quoted $500 for VMS and $500 for TCP/IP, so I guess that might
be their flat fee quote for any of the PAKs...

So $500*X. How large is X? 20?

[John E. Malmberg]

Post by Alice Wyan

Post by Dave Froble
I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.

I was quoted $500 for VMS and $500 for TCP/IP, so I guess that might
be their flat fee quote for any of the PAKs...

There are several variants of the VMS paks, ranging from ones that just
allow console + one logins to ones that allow unlimited users.

And some paks can limited or restricted to a specific hardware model
which needs to be specified at the purchase time.

So it may matter what the actual VMS pack being sold is.

Assuming that only a VAX/VMS pak is able to be purchased.

The free CMU/IP stopped work at supporting the early OpenVMS/VAX 6.x
releases. The source for the last few bug fixes never got released
before the distribution site was shutdown. Not sure if or where he rest
of the code got archived.

The GCC/VAX for 2.7.1 can be found on freeware. The source to the
GCC.EXE image which then invokes the actual compiler steps as
subprocesses has been lost. The source accompanying the binaries does
not match or build into the GCC.EXE binary.

We do not know how long Process will be offering a Hobby license for
VAX, as far as that option for TCP/IP.

Regards,
-John

[Alexander Schreiber]

Post by Alice Wyan

Post by Dave Froble
I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.

I was quoted $500 for VMS and $500 for TCP/IP, so I guess that might be their flat fee quote for any of the PAKs...

Darn, if you really want to play with the system, that would pile up
rather quickly. Dropping a couple grand on "I want to play with this"
would definitely be out of my range.

Kind regards,
Alex.

[Dave Froble]

Post by Dave Froble

Post by John E. Malmberg
"Users who wish to avail of HPE OpenVMS long term licenses are
encouraged to purchase permanent licenses at standard prices. You may
contact [Fellman, Jon] <jon.fellman at hpe.com> for the same."

Well, I did ask.
---
Do you just need VMS base?
Thank you,
Jon Fellman
Product Manager
Hewlett-Packard Financial Services
C#508-250-3676
Skype#508-467-0134
FX#978-474-2665
---
Notice where he works ...
I replied that I'm interested in VMS, TCP/IP, DECnet, and Basic.
So far I have not heard back.

Now I've heard back from Jon.

-------
My apologies for the delay.

QL-001AC-BB OVMS VAX 1 USER LICENSE $600

QL-36PAB-AA NAS CL 150 V/V TRAD LIC $500

QL-095AA-2B DEC BASIC VMS PERS LIC $500


The NAS150 will include DECNET E/N (QL-D04xx-xx) & TCP/IP (QL-GL7xx-xx)
in the software package.




Thank you,

Jon Fellman
--------

One thing I noticed. Jon appears to work for "Hewlett-Packard Financial
Services". Now, I'm not familiar with the HP/HPe split, but, I'm
wondering if we're hearing from an HP person, not an HPe person.

Curiosier and curiosier ....

Post by Dave Froble

Post by John E. Malmberg
I do not know what the current standard prices are for a license.
The price may still vary based on the size of the system.
And license are needed for every Layered Product or SIP that are used.
If someone knows those prices and are not restricted from posting them,
it might be nice to see them.
I do not know how long that offer is valid for either.

If I ever get that info, I'll post it here.

Post by John E. Malmberg
As far as contacting HPE at a level that could make that decision, I
have no idea where to start. If you own any HPE stock, you can make a
stock-holder's request for the board to vote on at the next election.

Now, this is the best idea I've heard yet. Mention the past hobbyist
program(s), that HPe has no forthcoming revenue from VAX/VMS, and the
"goodness" of promoting historical things.
Find someone with stock, or, purchase a share. Who knows, might even
make some money when selling it.

[Alexander Schreiber]

Post by John E. Malmberg

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

As I understand it, VSI only has the rights to distribute and license
software binaries that they have built and tested.
This does not restrict them from producing a VAX release, but they do
not have the resources add a VAX build to their backlog of work.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a
hobbyist collective that could be set up to preserve this system? I
guess there'd be quite a legal mess of rights behind the old code,
but... would it be a doable thing? What sort of money could we be
talking about to get this sort of transfer done?

"Users who wish to avail of HPE OpenVMS long term licenses are
encouraged to purchase permanent licenses at standard prices. You may
contact [Fellman, Jon] <jon.fellman at hpe.com> for the same."
I do not know what the current standard prices are for a license.
The price may still vary based on the size of the system.
And license are needed for every Layered Product or SIP that are used.
If someone knows those prices and are not restricted from posting them,
it might be nice to see them.

I would be very interested in seeing those prices, especially when
the target "hardware" is simulated (i.e. SIMH). Although I suspect
those prices would be significantly above what I'd be willing to
pay for my non-commercial, hobbyist "just playing around" use case.

Post by John E. Malmberg
I think I am going to try NetBSD/VAX out.

Be aware that gcc for VAX is not in a very good shape (it builds the
system, but some ports are ... dicey), although it is currently
actively being worked on. The ports-vax NetBSD mailing list has the
relevant discussions.

And speaking from experience: SIMH provides a nice MicroVAX 3800
on which NetBSD/vax works in a quite useable manner. I (sadly)
have no experience with _actual_ hardware.

Kind regards,
Alex.

[Phillip Helbig (undress to reply)]

Post by Alexander Schreiber
I would be very interested in seeing those prices, especially when
the target "hardware" is simulated

Why should that make a difference?

[Bob Eager]

On Mon, 20 Jul 2020 07:22:09 +0000, Phillip Helbig (undress to reply)

Post by Phillip Helbig (undress to reply)

I would be very interested in seeing those prices, especially when the
target "hardware" is simulated

Why should that make a difference?

Because...

Post by Phillip Helbig (undress to reply)
I have no idea if this is still the current status, but it is the latest
https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games distributed
in formats that have become obsolete and which require the original
media or hardware as a condition of access." That may be applicable to
the current situation.

[Alexander Schreiber]

Post by Phillip Helbig (undress to reply)

Post by Alexander Schreiber
I would be very interested in seeing those prices, especially when
the target "hardware" is simulated

Why should that make a difference?

I'm not very familiar with the VMS pricing, but I know a few companies
where the "machine size" is a factor in license cost. And other setups
that will only license to physical hardware, refusing to license simulated
setups (basically using the hardware as part of the license key).

Kind regards,
Alex.

[Arne Vajhøj]

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially
abandoned.

VMS VAX became EOL years ago.

Only recent event is that HPE dropped VMS hobbyist program and that
the VSI replacement will not include VMS VAX because VSI can only issue
licenses for VSI VMS and they will not release VSI VMS for VAX.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a
hobbyist collective that could be set up to preserve this system? I
guess there'd be quite a legal mess of rights behind the old code,
but... would it be a doable thing? What sort of money could we be
talking about to get this sort of transfer done?

Possible? Yes.

Likely? No.

The relevant point is not that "it will not cost HPE much"
but "it will not gain HPE much".

Why would they want to do it??

Arne

[Phillip Helbig (undress to reply)]

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right. I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

Post by Alice Wyan
What sort of money could we be talking about to get this sort of
transfer done?

No idea. Of course, money talks, bullshit walks. I'm sure that they
would consider an offer which worked out to a good hourly wage for all
involved. I have no idea how high such an offer must be.

Legally, there is no concept of "abandonware". Even if no-one is making
money from it, no-one cares about it, etc., that doesn't give anyone any
extra rights. A more viable solution might be to buy, for whatever
price you agree on, non-hobbyist licenses (which won't expire). There
used to be a transfer fee of $300. I don't know who handles that now.
But if you buy such a license and send a registered letter to HPE asking
how to pay the transfer fee, then I doubt that you would have any
problems if they don't answer.

[John Reagan]

Post by Phillip Helbig (undress to reply)

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right. I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

I have said several times, to several people, in several forums: The day you ask me to starting making VAX compilers again is the day we'll start planning my retirement party. I ain't got no time for that stuff. The thought of the VAX VCG and PL/1 (much of the VCG is written in PL/1) is a hard NO. I will use my safeword on that one.

[Phillip Helbig (undress to reply)]

Post by John Reagan
I have said several times, to several people, in several forums: The day
you ask me to starting making VAX compilers again is the day we'll start
planning my retirement party. I ain't got no time for that stuff. The
thoughtof the VAX VCG and PL/1 (much of the VCG is written in PL/1) is a
hard NO. I will use my safeword on that one.

I don't think any VAX hobbyist seriously expects any work on VAX
compilers. Almost all would be more than happy to have a license to
allow them to run whatever VAX stuff they have now.

[Bill Gunshannon]

Post by John Reagan

Post by Phillip Helbig (undress to reply)

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right. I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

I have said several times, to several people, in several forums: The day you ask me to starting making VAX compilers again is the day we'll start planning my retirement party. I ain't got no time for that stuff. The thought of the VAX VCG and PL/1 (much of the VCG is written in PL/1) is a hard NO. I will use my safeword on that one.

What happened to the compilers that were used to build VAX
versions in the past? I would have thought there was one
big archive with everything VAX related in it. Were they
really so incompetent that they lost some of it? I would
have expected that all it would really take for someone new
to build a VAX version of VMS today would be to have the
archive and a machine (today, probably an emulated system)
to load it on and run the build process.

bill

[Craig A. Berry]

Post by Bill Gunshannon

Post by John Reagan

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right.  I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

I have said several times, to several people, in several forums: The
day you ask me to starting making VAX compilers again is the day we'll
start planning my retirement party.  I ain't got no time for that
stuff.  The thought of the VAX VCG and PL/1 (much of the VCG is
written in PL/1) is a hard NO.  I will use my safeword on that one.

What happened to the compilers that were used to build VAX
versions in the past?  I would have thought there was one
big archive with everything VAX related in it.  Were they
really so incompetent that they lost some of it?  I would
have expected that all it would really take for someone new
to build a VAX version of VMS today would be to have the
archive and a machine (today, probably an emulated system)
to load it on and run the build process.

No one said anything was lost. The context was the prospect of having
VSI produce a VAX release, which would be necessary before they could
issue licenses (hobbyist or otherwise) for VAX, but which they have said
numerous times they aren't going to do. In that context, John is
obviously talking about *maintaining* the VCG compilers, which he would
have to do if VSI were producing VAX releases. Or not maintaining them,
since he would quit first.

Now, if some bored computer science students with nothing to do during
the pandemic would update llvm-alpha and produce an llvm-vax code
generator, everything would be gravy :-). Except John would probably
still quit if he had to make the LLVM-based compilers with the GEM
emulation target VAX since the GEM-based compilers are likely full of
post-VAX assumptions.

[Bill Gunshannon]

Post by Bill Gunshannon

Post by John Reagan

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right.  I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

I have said several times, to several people, in several forums: The
day you ask me to starting making VAX compilers again is the day
we'll start planning my retirement party.  I ain't got no time for
that stuff.  The thought of the VAX VCG and PL/1 (much of the VCG is
written in PL/1) is a hard NO.  I will use my safeword on that one.

What happened to the compilers that were used to build VAX
versions in the past?  I would have thought there was one
big archive with everything VAX related in it.  Were they
really so incompetent that they lost some of it?  I would
have expected that all it would really take for someone new
to build a VAX version of VMS today would be to have the
archive and a machine (today, probably an emulated system)
to load it on and run the build process.

No one said anything was lost.  The context was the prospect of having
VSI produce a VAX release, which would be necessary before they could
issue licenses (hobbyist or otherwise) for VAX, but which they have said
numerous times they aren't going to do. In that context, John is
obviously talking about *maintaining* the VCG compilers, which he would
have to do if VSI were producing VAX releases.  Or not maintaining them,
since he would quit first.

VAX VMS isn't maintained now. Hasn't been for, I don't klnow, a
decade maybe. No one is asking for it to be maintained. The
assumption was (at least on my part) that the archive of the
system used to create the last release of VAX VMS still existed.
If that is the case all that should need to be done is to load
it on a system (probably emulated and thus likely to be much faster
than the system last used to build it) and run the build scripts.
I always thought VMS engineering was professional enough (at least
when it was still done by people like Hoff) that the system was
smooth and maybe even documented.

If desired they could change the startup banner to reflect VSI
taking over, but no change to any of the code would be necessary.

Now, if some bored computer science students with nothing to do during
the pandemic would update llvm-alpha and produce an llvm-vax code
generator, everything would be gravy :-).  Except John would probably
still quit if he had to make the LLVM-based compilers with the GEM
emulation target VAX since the GEM-based compilers are likely full of
post-VAX assumptions.

If they weren't the compilers used in the past, why would you need
them now for a "one-off" run?

bill

[Dave Froble]

Post by Bill Gunshannon

Post by Craig A. Berry

Post by Bill Gunshannon

On Friday, July 17, 2020 at 12:41:58 PM UTC-4, Phillip Helbig

Post by Phillip Helbig (undress to reply)

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right. I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

I have said several times, to several people, in several forums: The
day you ask me to starting making VAX compilers again is the day
we'll start planning my retirement party. I ain't got no time for
that stuff. The thought of the VAX VCG and PL/1 (much of the VCG is
written in PL/1) is a hard NO. I will use my safeword on that one.

What happened to the compilers that were used to build VAX
versions in the past? I would have thought there was one
big archive with everything VAX related in it. Were they
really so incompetent that they lost some of it? I would
have expected that all it would really take for someone new
to build a VAX version of VMS today would be to have the
archive and a machine (today, probably an emulated system)
to load it on and run the build process.

No one said anything was lost. The context was the prospect of having
VSI produce a VAX release, which would be necessary before they could
issue licenses (hobbyist or otherwise) for VAX, but which they have said
numerous times they aren't going to do. In that context, John is
obviously talking about *maintaining* the VCG compilers, which he would
have to do if VSI were producing VAX releases. Or not maintaining them,
since he would quit first.

VAX VMS isn't maintained now. Hasn't been for, I don't klnow, a
decade maybe. No one is asking for it to be maintained. The
assumption was (at least on my part) that the archive of the
system used to create the last release of VAX VMS still existed.
If that is the case all that should need to be done is to load
it on a system (probably emulated and thus likely to be much faster
than the system last used to build it) and run the build scripts.
I always thought VMS engineering was professional enough (at least
when it was still done by people like Hoff) that the system was
smooth and maybe even documented.
If desired they could change the startup banner to reflect VSI
taking over, but no change to any of the code would be necessary.

Post by Craig A. Berry
Now, if some bored computer science students with nothing to do during
the pandemic would update llvm-alpha and produce an llvm-vax code
generator, everything would be gravy :-). Except John would probably
still quit if he had to make the LLVM-based compilers with the GEM
emulation target VAX since the GEM-based compilers are likely full of
post-VAX assumptions.

If they weren't the compilers used in the past, why would you need
them now for a "one-off" run?
bill

I'd think that nothing new would be required. So John might be safe.

However I do believe that both Clair and Steve have touched on this
subject in the past. Some of the things I recall:

The build was spread over multiple systems

The build was not 100% automated (big issue)

The build included things beyond compiling and linking

The build instructions might be lost

The issue then is, someone would have to find or implement a build, and
that wasn't going to be simple, easy, or short.

None of which matters. The VAX/VMS V7.3 distribution is all that's
needed, from a software perspective, and I'm sure multiple people have
it, I know I have a CD with the distribution.

The issues are permissions and LMF.

[Bob Wilson]

Post by Dave Froble
However I do believe that both Clair and Steve have touched on this
The build was spread over multiple systems
The build was not 100% automated (big issue)
The build included things beyond compiling and linking
The build instructions might be lost
The issue then is, someone would have to find or implement a build, and
that wasn't going to be simple, easy, or short.
None of which matters. The VAX/VMS V7.3 distribution is all that's
needed, from a software perspective, and I'm sure multiple people have
it, I know I have a CD with the distribution.

If you're talking about the VAX VMS system build...

The VAX build was similar to but a bit different than the Alpha, IA64 or x86 builds...but anyone doing VMS builds today would recognize it (yes, it's a small number).

One of the last things that I did before they shut down the VAX VMS build environment was to save a copy of the VAX master pack (which is not the same as the Alpha [of the time] master pack -- nowadays Alpha=IA64=x86 [some differing architecture specific facilities, but a *lot* of common code]...the VAX master pack content was never integrated into the Alpha master pack).

If I had a couple of VAX systems [in a cluster] I could probably get it to build again (V7.3) ... stuff was checked in [on the VAX master pack] later(after V7.3) to track changes that were taking place on "the Alpha side" but there were divergences after V7.3 in some facilities (like RMS, I think) and we didn't really have a usable VAX result disk by the time stuff got shipped off to the other side of the world.

The VAX VMS build system was a VAX7660 (a six-cpu "Laser platform based" XMI I/O-based system with CI attached storage, HSJ's I think) and it took about 30 minutes to do the O/S part of the build--there were other VAX6000 series system in the same cluster but they were inconsequential in terms of CPU capability (all being non-XMI2 based configs) . I'd guess that a nicely configured VAX emulator could get it done in much less time (and if you could cluster two of them, even better!)

From V7.0 onward the build tools were all under revision control on the master pack and were fetched off of the master pack [to the result disk] as part of the VMS build setup process (using a tool called VMSGEN :-)). V6.2 (and earlier) was built with whatever was installed on the "running system" (vs. the "build tools on result disk" model that was always used on Alpha [from V1.0], and adopted later for VAX [in V7.0...though using a somewhat different model then used on Alpha])...so there's no hope of building any version of VAX VMS (or VAX/VMS) before V7.0.

While the VAX master pack was saved, I didn't make a copy of the VDE disk (tip of hat to Steve H), which would be required to checkin any changes to it (the VAX master pack is a bunch of CMS libraries...so changes could be checked in via CMS directly, but it would be rather cumbersome to manage 200+ CMS libraries that way).


bw (VMS Build and Release -- VAX/Alpha/IA64/x86)

[Stephen Hoffman]

Post by Bob Wilson

Post by Dave Froble
However I do believe that both Clair and Steve have touched on this
The build was spread over multiple systems
The build was not 100% automated (big issue)
The build included things beyond compiling and linking
The build instructions might be lost
The issue then is, someone would have to find or implement a build, and
that wasn't going to be simple, easy, or short.
None of which matters. The VAX/VMS V7.3 distribution is all that's
needed, from a software perspective, and I'm sure multiple people have
it, I know I have a CD with the distribution.

If you're talking about the VAX VMS system build...
The VAX build was similar to but a bit different than the Alpha, IA64
or x86 builds...but anyone doing VMS builds today would recognize it
(yes, it's a small number).
One of the last things that I did before they shut down the VAX VMS
build environment was to save a copy of the VAX master pack (which is
not the same as the Alpha [of the time] master pack -- nowadays
Alpha=IA64=x86 [some differing architecture specific facilities, but a
*lot* of common code]...the VAX master pack content was never
integrated into the Alpha master pack).
If I had a couple of VAX systems [in a cluster] I could probably get it
to build again (V7.3) ... stuff was checked in [on the VAX master pack]
later(after V7.3) to track changes that were taking place on "the Alpha
side" but there were divergences after V7.3 in some facilities (like
RMS, I think) and we didn't really have a usable VAX result disk by the
time stuff got shipped off to the other side of the world.
The VAX VMS build system was a VAX7660 (a six-cpu "Laser platform
based" XMI I/O-based system with CI attached storage, HSJ's I think)
and it took about 30 minutes to do the O/S part of the build--there
were other VAX6000 series system in the same cluster but they were
inconsequential in terms of CPU capability (all being non-XMI2 based
configs) . I'd guess that a nicely configured VAX emulator could get it
done in much less time (and if you could cluster two of them, even
better!)
From V7.0 onward the build tools were all under revision control on the
master pack and were fetched off of the master pack [to the result
disk] as part of the VMS build setup process (using a tool called
VMSGEN :-)). V6.2 (and earlier) was built with whatever was installed
on the "running system" (vs. the "build tools on result disk" model
that was always used on Alpha [from V1.0], and adopted later for VAX
[in V7.0...though using a somewhat different model then used on
Alpha])...so there's no hope of building any version of VAX VMS (or
VAX/VMS) before V7.0.
While the VAX master pack was saved, I didn't make a copy of the VDE
disk (tip of hat to Steve H), which would be required to checkin any
changes to it (the VAX master pack is a bunch of CMS libraries...so
changes could be checked in via CMS directly, but it would be rather
cumbersome to manage 200+ CMS libraries that way).

The 32-bit VAX source code control environment was made common across
the various OpenVMS development environments, including migrating to
the use of VDE across the 32- and 64-bit environments. That
development environment was originally a mixed-architecture VAX and
Alpha cluster for 32-bit (STAR::) and a mixed-architecture Alpha and
Itanium cluster for 64-bit (EVMS::). That work toward common source
code control tooling was not tied to an OpenVMS release, but was an
incremental process that happened through the V6.2 timeframe.

VDE itself was portable, and able to build and operate VDE itself on
all three architectures. The build tooling remained separate from the
source code control tooling, as Bob mentions.

In addition to porting the source code control environment around, I've
also ported the 64-bit OpenVMS build environment around for
tool-testing purposes, and that port took a few days to get
mostly-working on a testing-configured AlphaServer system.

The source code control and VDE environment was a PCSI kit, starting
around Y2K. See VDE on the OpenVMS Freeware for details. AFAIK, the
build environment was not packaged.

Approximately nobody was working with the 32-bit build environment
after V7.3, save for building incremental fixes. Source code control
was still active, as were targeted builds for patches. I don't recall
if there were any full builds after V7.3 shipped, but there would not
have been very many of those.

The source code control tool VDE itself was under source control in a
VDE library, as well as a separate VDE library containing the
regression test suite and the pieces necessary for testing Rdb database
upgrades, and for testing VDE database changes.

Results disks were used for new builds with new results disks, and for
building fixes that didn't necessitate running a complete system build.
Getting a build would require either a results disk, or manually
recreating a results disk. This'll be part of the difficulty that Bob
mentions about restarting the older 32-bit builds.

Parts of the hardware environment were on DSA-class storage through the
early V6 range (and using host-based RAID-1 HBVS shadowing and
software-toggling RA disks between clusters was common), was then
stored on HSJ for a while—had a *wonderful* time with an HSJ-triggered
Rdb database corruption—and the database storage was then migrated to
EVA storage, IIRC. EVA was massively faster than the HSJ storage. The
32-bit and 64-bit environments remained separate, the rest of the
hardware used moved around.

Beyond the rest of the mess, the 32-bit layered products including
TCP/IP Services—which really shouldn't be a layered product—or its
replacement VSI IP stack, will have to be rebuilt to get anywhere with
the 32-bit environment.

The OpenVMS source listings CD that David is referencing in the quoted
text above are expurgated listings. There are facilities and files
omitted from that. And components such as the checked-in compilers and
tools were not included in that. Nor the build procedures, for that
matter.

And circling back to the original discussion, I expect that a fair
portion of the hobbyist interest in the 32-bit OpenVMS VAX will drop
off for a lot of folks as the OpenVMS x86-64 native environment becomes
available to hobbyists, too. But HPE are the folks y'all want to
discuss this with, if y'all want legitimate HPE OpenVMS VAX V7.3
hobbyist licenses past the end of 2021. Or buy licenses from HPE,
before they stop selling those. And if they're offering NAS PAKs for
the same price, ask for the upper-tier NAS PAKs and not the lower-tier
PAKs.

[Dave Froble]

Post by Stephen Hoffman

Post by Bob Wilson

Post by Dave Froble
However I do believe that both Clair and Steve have touched on this
The build was spread over multiple systems
The build was not 100% automated (big issue)
The build included things beyond compiling and linking
The build instructions might be lost
The issue then is, someone would have to find or implement a build,
and that wasn't going to be simple, easy, or short.
None of which matters. The VAX/VMS V7.3 distribution is all that's
needed, from a software perspective, and I'm sure multiple people
have it, I know I have a CD with the distribution.

If you're talking about the VAX VMS system build...
The VAX build was similar to but a bit different than the Alpha, IA64
or x86 builds...but anyone doing VMS builds today would recognize it
(yes, it's a small number).
One of the last things that I did before they shut down the VAX VMS
build environment was to save a copy of the VAX master pack (which is
not the same as the Alpha [of the time] master pack -- nowadays
Alpha=IA64=x86 [some differing architecture specific facilities, but a
*lot* of common code]...the VAX master pack content was never
integrated into the Alpha master pack).
If I had a couple of VAX systems [in a cluster] I could probably get
it to build again (V7.3) ... stuff was checked in [on the VAX master
pack] later(after V7.3) to track changes that were taking place on
"the Alpha side" but there were divergences after V7.3 in some
facilities (like RMS, I think) and we didn't really have a usable VAX
result disk by the time stuff got shipped off to the other side of the
world.
The VAX VMS build system was a VAX7660 (a six-cpu "Laser platform
based" XMI I/O-based system with CI attached storage, HSJ's I think)
and it took about 30 minutes to do the O/S part of the build--there
were other VAX6000 series system in the same cluster but they were
inconsequential in terms of CPU capability (all being non-XMI2 based
configs) . I'd guess that a nicely configured VAX emulator could get
it done in much less time (and if you could cluster two of them, even
better!)
From V7.0 onward the build tools were all under revision control on
the master pack and were fetched off of the master pack [to the result
disk] as part of the VMS build setup process (using a tool called
VMSGEN :-)). V6.2 (and earlier) was built with whatever was installed
on the "running system" (vs. the "build tools on result disk" model
that was always used on Alpha [from V1.0], and adopted later for VAX
[in V7.0...though using a somewhat different model then used on
Alpha])...so there's no hope of building any version of VAX VMS (or
VAX/VMS) before V7.0.
While the VAX master pack was saved, I didn't make a copy of the VDE
disk (tip of hat to Steve H), which would be required to checkin any
changes to it (the VAX master pack is a bunch of CMS libraries...so
changes could be checked in via CMS directly, but it would be rather
cumbersome to manage 200+ CMS libraries that way).

The 32-bit VAX source code control environment was made common across
the various OpenVMS development environments, including migrating to the
use of VDE across the 32- and 64-bit environments. That development
environment was originally a mixed-architecture VAX and Alpha cluster
for 32-bit (STAR::) and a mixed-architecture Alpha and Itanium cluster
for 64-bit (EVMS::). That work toward common source code control
tooling was not tied to an OpenVMS release, but was an incremental
process that happened through the V6.2 timeframe.
VDE itself was portable, and able to build and operate VDE itself on all
three architectures. The build tooling remained separate from the
source code control tooling, as Bob mentions.
In addition to porting the source code control environment around, I've
also ported the 64-bit OpenVMS build environment around for tool-testing
purposes, and that port took a few days to get mostly-working on a
testing-configured AlphaServer system.
The source code control and VDE environment was a PCSI kit, starting
around Y2K. See VDE on the OpenVMS Freeware for details. AFAIK, the
build environment was not packaged.
Approximately nobody was working with the 32-bit build environment after
V7.3, save for building incremental fixes. Source code control was
still active, as were targeted builds for patches. I don't recall if
there were any full builds after V7.3 shipped, but there would not have
been very many of those.
The source code control tool VDE itself was under source control in a
VDE library, as well as a separate VDE library containing the regression
test suite and the pieces necessary for testing Rdb database upgrades,
and for testing VDE database changes.
Results disks were used for new builds with new results disks, and for
building fixes that didn't necessitate running a complete system build.
Getting a build would require either a results disk, or manually
recreating a results disk. This'll be part of the difficulty that Bob
mentions about restarting the older 32-bit builds.
Parts of the hardware environment were on DSA-class storage through the
early V6 range (and using host-based RAID-1 HBVS shadowing and
software-toggling RA disks between clusters was common), was then stored
on HSJ for a while—had a *wonderful* time with an HSJ-triggered Rdb
database corruption—and the database storage was then migrated to EVA
storage, IIRC. EVA was massively faster than the HSJ storage. The
32-bit and 64-bit environments remained separate, the rest of the
hardware used moved around.
Beyond the rest of the mess, the 32-bit layered products including
TCP/IP Services—which really shouldn't be a layered product—or its
replacement VSI IP stack, will have to be rebuilt to get anywhere with
the 32-bit environment.
The OpenVMS source listings CD that David is referencing in the quoted
text above are expurgated listings. There are facilities and files
omitted from that. And components such as the checked-in compilers and
tools were not included in that. Nor the build procedures, for that
matter.
And circling back to the original discussion, I expect that a fair
portion of the hobbyist interest in the 32-bit OpenVMS VAX will drop off
for a lot of folks as the OpenVMS x86-64 native environment becomes
available to hobbyists, too. But HPE are the folks y'all want to discuss
this with, if y'all want legitimate HPE OpenVMS VAX V7.3 hobbyist
licenses past the end of 2021. Or buy licenses from HPE, before they
stop selling those. And if they're offering NAS PAKs for the same
price, ask for the upper-tier NAS PAKs and not the lower-tier PAKs.

I had to take a day to think about Bob's post.

Ok, pure speculation ....

Would VSI allow a VSI sponsored VAX/VMS Version (whatever), or do they
have some reason they do not want there to be a new VAX/VMS version?

Assume VSI hired Bob for $1 (donated by Dave) to build a new VSI version
of VAX/VMS, which would not cost them anything, no time (other than to
say Ok), and they would never be bothered by it's existence.

Assume some entity (call if DECUS, if possible) made the distribution
available, along with the required PAKs.

So, Ok, would Bob be willing and able to produce the new version? Would
someone provide him with the resources to do so? Would someone host the
distribution and PAKs and whatever else?

Just wondering ....

Gauntlet cast down ....

:-)

[Phillip Helbig (undress to reply)]

Post by Dave Froble
Would VSI allow a VSI sponsored VAX/VMS Version (whatever), or do they
have some reason they do not want there to be a new VAX/VMS version?
Assume VSI hired Bob for $1 (donated by Dave) to build a new VSI version
of VAX/VMS, which would not cost them anything, no time (other than to
say Ok), and they would never be bothered by it's existence.
Assume some entity (call if DECUS, if possible) made the distribution
available, along with the required PAKs.
So, Ok, would Bob be willing and able to produce the new version? Would
someone provide him with the resources to do so? Would someone host the
distribution and PAKs and whatever else?

Why should VSI be involved at all? If I understand things correctly,
HPE could take that dollar. VSI isn't in the VAX picture at all.

[Bill Gunshannon]

Post by Phillip Helbig (undress to reply)

Post by Dave Froble
Would VSI allow a VSI sponsored VAX/VMS Version (whatever), or do they
have some reason they do not want there to be a new VAX/VMS version?
Assume VSI hired Bob for $1 (donated by Dave) to build a new VSI version
of VAX/VMS, which would not cost them anything, no time (other than to
say Ok), and they would never be bothered by it's existence.
Assume some entity (call if DECUS, if possible) made the distribution
available, along with the required PAKs.
So, Ok, would Bob be willing and able to produce the new version? Would
someone provide him with the resources to do so? Would someone host the
distribution and PAKs and whatever else?

Why should VSI be involved at all? If I understand things correctly,
HPE could take that dollar. VSI isn't in the VAX picture at all.

Because HPE is no longer in the picture at all. VSI is the only
game in town.

bill

[Dave Froble]

Post by Phillip Helbig (undress to reply)

Post by Dave Froble
Would VSI allow a VSI sponsored VAX/VMS Version (whatever), or do they
have some reason they do not want there to be a new VAX/VMS version?
Assume VSI hired Bob for $1 (donated by Dave) to build a new VSI version
of VAX/VMS, which would not cost them anything, no time (other than to
say Ok), and they would never be bothered by it's existence.
Assume some entity (call if DECUS, if possible) made the distribution
available, along with the required PAKs.
So, Ok, would Bob be willing and able to produce the new version? Would
someone provide him with the resources to do so? Would someone host the
distribution and PAKs and whatever else?

Why should VSI be involved at all? If I understand things correctly,
HPE could take that dollar. VSI isn't in the VAX picture at all.

You haven't been reading, or comprehending a damn thing.

HPe is out of the picture as far as VMs is concerned. By their own choice.

VSI is the entity that can produce new versions, and then distribute and
allow use of said new versions.

Any usage of VAX/VMS therefore must come from VSI.

VSI does not want to spend one penny on VAX.
VSI does not want to spend one minute on VAX.

Which part of the above do you not understand?

[Michael Moroney]

Post by Dave Froble

Post by Phillip Helbig (undress to reply)

Post by Dave Froble
Would VSI allow a VSI sponsored VAX/VMS Version (whatever), or do they
have some reason they do not want there to be a new VAX/VMS version?
Assume VSI hired Bob for $1 (donated by Dave) to build a new VSI version
of VAX/VMS, which would not cost them anything, no time (other than to
say Ok), and they would never be bothered by it's existence.
Assume some entity (call if DECUS, if possible) made the distribution
available, along with the required PAKs.
So, Ok, would Bob be willing and able to produce the new version? Would
someone provide him with the resources to do so? Would someone host the
distribution and PAKs and whatever else?

Why should VSI be involved at all? If I understand things correctly,
HPE could take that dollar. VSI isn't in the VAX picture at all.

You haven't been reading, or comprehending a damn thing.
HPe is out of the picture as far as VMs is concerned. By their own choice.
VSI is the entity that can produce new versions, and then distribute and
allow use of said new versions.
Any usage of VAX/VMS therefore must come from VSI.
VSI does not want to spend one penny on VAX.
VSI does not want to spend one minute on VAX.
Which part of the above do you not understand?

In addition:

HPE still owns VAX/VMS. Unlike the Alpha/Itanium version, VSI did NOT get any
rights to VAX/VMS. Like it or not, HPE still owns VAX/VMS outright, for them
to ignore. And as pointed out, VSI has no interest in VAX/VMS.

[Michael Moroney]

Post by Michael Moroney
HPE still owns VAX/VMS. Unlike the Alpha/Itanium version, VSI did NOT get any
rights to VAX/VMS. Like it or not, HPE still owns VAX/VMS outright, for them
to ignore. And as pointed out, VSI has no interest in VAX/VMS.

I got a little mixed up. I was in part replying to Dave, and in part to
Phillip. But you can figure out what I mean. HPE still owns VAX/VMS. VSI has
no rights to VAX/VMS. VSI is not at all interested in VAX/VMS. Anyone who
wants VAX licenses needs to convince HPE, not VSI, to produce them. And good
luck with finding anyone at HPE management to listen, or who even knows what a
VAX is.

[Robert A. Brooks]

HPE still owns VAX/VMS. VSI has no rights to VAX/VMS.

It's never pretty to see VSI-on-VSI violence, but I must disagree with my
esteemed colleague here.

Mike, we *do* have the rights (and the VAX master pack, including the
Emerald builds) to produce a VSI version of OpenVMS VAX.

We have chosen not to do that; we don't want Reagan to retire.

[Dave Froble]

Post by Robert A. Brooks

HPE still owns VAX/VMS. VSI has no rights to VAX/VMS.

It's never pretty to see VSI-on-VSI violence, but I must disagree with
my esteemed colleague here.
Mike, we *do* have the rights (and the VAX master pack, including the
Emerald builds) to produce a VSI version of OpenVMS VAX.
We have chosen not to do that; we don't want Reagan to retire.

If I had only waited a bit, this would have saved me all that tedious
research ...

:-(

[David Goodwin]

Post by Robert A. Brooks

HPE still owns VAX/VMS. VSI has no rights to VAX/VMS.

It's never pretty to see VSI-on-VSI violence, but I must disagree with my
esteemed colleague here.
Mike, we *do* have the rights (and the VAX master pack, including the
Emerald builds) to produce a VSI version of OpenVMS VAX.
We have chosen not to do that; we don't want Reagan to retire.

Any chance of someone at VSI talking to their contacts at HPE to try and rescue the hobbyist program for VAX? Perhaps have something setup on Eisner to generate hobbyist licenses? Or just issue some non-expiring ones?

Would be a shame to see VAX VMS just disappear. I don't know running NetBSD on a VAX is nearly as interesting.

[Michael Moroney]

Post by Robert A. Brooks

HPE still owns VAX/VMS. VSI has no rights to VAX/VMS.

It's never pretty to see VSI-on-VSI violence, but I must disagree with my
esteemed colleague here.
Mike, we *do* have the rights (and the VAX master pack, including the
Emerald builds) to produce a VSI version of OpenVMS VAX.

I know we have the VAX master pack (I've looked through it to see how X was
done on VAX) but I thought it was included by accident with all the other stuff
we got from Bangalore. Also I distinctly remember in the early days being told
we didn't have rights to VAX at all, and someone did joke that it was legal
under the contract to 'port VMS to VAX' since we have the rights to port VMS to
anything.

Post by Robert A. Brooks
We have chosen not to do that; we don't want Reagan to retire.

Noble cause.

[Simon Clubley]

Post by Robert A. Brooks

HPE still owns VAX/VMS. VSI has no rights to VAX/VMS.

It's never pretty to see VSI-on-VSI violence, but I must disagree with my
esteemed colleague here.
Mike, we *do* have the rights (and the VAX master pack, including the
Emerald builds) to produce a VSI version of OpenVMS VAX.
We have chosen not to do that; we don't want Reagan to retire.

You've made that clear many, many, times now. :-)

On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.

Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

Simon.

[Arne Vajhøj]

Post by Simon Clubley
On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.
Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

When you say VAXELN do you mean the VMS source code for the tools
running on VMS generating VAXELN code or do you mean the source code
for the VAXELN stuff?

(the answer may be the same but it could be different)

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley
On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.
Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

When you say VAXELN do you mean the VMS source code for the tools
running on VMS generating VAXELN code or do you mean the source code
for the VAXELN stuff?
(the answer may be the same but it could be different)

For all practical purposes, they are the same thing.

I don't know how much experience you have with embedded systems, but
with tools like VAXELN, the libraries used to construct the final
bootable system images ship as part of VAXELN.

You use a VAXELN compiler running on VMS (such as the VAXELN version
of Pascal) to compile your source code and then you use another VAXELN
tool, also running on VMS, to generate the final system image that is
then booted on the target system.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.
Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

When you say VAXELN do you mean the VMS source code for the tools
running on VMS generating VAXELN code or do you mean the source code
for the VAXELN stuff?
(the answer may be the same but it could be different)

For all practical purposes, they are the same thing.
I don't know how much experience you have with embedded systems, but
with tools like VAXELN, the libraries used to construct the final
bootable system images ship as part of VAXELN.
You use a VAXELN compiler running on VMS (such as the VAXELN version
of Pascal) to compile your source code and then you use another VAXELN
tool, also running on VMS, to generate the final system image that is
then booted on the target system.

I know that.

And the first is obviously useless without the second.

But while the first is running on VMS then the second is not.

Which could mean a difference per the contract between HPE and VSI.

You could argue that if they are treated different in the contract
then it an error in the contract, but I doubt anyone was thinking about
VAXELN when the drafted the contract.

Arne

[Jan-Erik Söderholm]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Arne Vajhøj

Post by Simon Clubley
On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.
Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

When you say VAXELN do you mean the VMS source code for the tools
running on VMS generating VAXELN code or do you mean the source code
for the VAXELN stuff?
(the answer may be the same but it could be different)

For all practical purposes, they are the same thing.
I don't know how much experience you have with embedded systems, but
with tools like VAXELN, the libraries used to construct the final
bootable system images ship as part of VAXELN.
You use a VAXELN compiler running on VMS (such as the VAXELN version
of Pascal) to compile your source code and then you use another VAXELN
tool, also running on VMS, to generate the final system image that is
then booted on the target system.

I know that.
And the first is obviously useless without the second.
But while the first is running on VMS then the second is not.
Which could mean a difference per the contract between HPE and VSI.
You could argue that if they are treated different in the contract
then it an error in the contract, but I doubt anyone was thinking about
VAXELN when the drafted the contract.
Arne

And what say the sites still using/running VAXELN? A major kitchen
applience manufacturer in Sweden had multiple VAXELN system for
their assembly lines up to at least 3-4 years ago. Not sure of
the actual status today...

[Arne Vajhøj]

Post by Jan-Erik Söderholm
And what say the sites still using/running VAXELN? A major kitchen
applience manufacturer in Sweden had multiple VAXELN system for
their assembly lines up to at least 3-4 years ago. Not sure of
the actual status today...

What about them? They must have licenses. And I assume
support on the involved SW and HW has ran out many years ago.

If I were in their shoes I would consider the platform a
business risk and create a roadmap to get on a supported
platform. But we all know that not everyone feel that way.

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Jan-Erik Söderholm
And what say the sites still using/running VAXELN? A major kitchen
applience manufacturer in Sweden had multiple VAXELN system for
their assembly lines up to at least 3-4 years ago. Not sure of
the actual status today...

What about them? They must have licenses. And I assume
support on the involved SW and HW has ran out many years ago.
If I were in their shoes I would consider the platform a
business risk and create a roadmap to get on a supported
platform. But we all know that not everyone feel that way.
Arne

Wonder why it is that those who stand to benefit the most from continual
scrapping what works and replacing it with new always suggest said
scrapping?

Most might feel that if it ain't broke, don't fix it.

Then there are IT people who say "we need the work, throw out and replace".

:-)

[Arne Vajhøj]

Post by Dave Froble
Wonder why it is that those who stand to benefit the most from continual
scrapping what works and replacing it with new always suggest said
scrapping?
Most might feel that if it ain't broke, don't fix it.
Then there are IT people who say "we need the work, throw out and replace".
:-)

There are a few good reasons to upgrade systems and a few bad reasons.

If we start with bad reasons then this is management covering their
ass by choosing the same as everybody else, management showing
"drive" by changing something just to change it etc..

Good reasons:

Even though something works just as well today as it did
25 years ago, then there may be a better solution today.
Non-IT example: horses still works fine, but most people
agree that cars are significantly better.

Even though something works right now, then there is no
guarantee that it will continue to work. Running obsolete stuff
is a risk. If the HW breaks can it be replaced. If something
changing breaks the SW can it be fixed. If the people running
the stuff quits can they be replaced. Running on current HW,
supported SW and widely used SW reduces risk. Non-IT example:
it is July and you are checking your roof and you can see that
the beams are seriously weakened - it will collapse if it
gets 2 feet or more of snow. Do you note that the roof is
working and that there is an OK chance that there will not
fall 2 feet of snow the coming winter and do nothing or do
you replace the roof.

Arne

[Dave Froble]

Post by Arne Vajhøj

Post by Dave Froble
Wonder why it is that those who stand to benefit the most from
continual scrapping what works and replacing it with new always
suggest said scrapping?
Most might feel that if it ain't broke, don't fix it.
Then there are IT people who say "we need the work, throw out and replace".
:-)

There are a few good reasons to upgrade systems and a few bad reasons.
If we start with bad reasons then this is management covering their
ass by choosing the same as everybody else, management showing
"drive" by changing something just to change it etc..

Or the IT guy that wants to get WEENDOZE or Linux on his resume? This
happens, I've seen it.

Post by Arne Vajhøj
Even though something works just as well today as it did
25 years ago, then there may be a better solution today.
Non-IT example: horses still works fine, but most people
agree that cars are significantly better.

For trial riding ?

"Better" is quite subjective.

Post by Arne Vajhøj
Even though something works right now, then there is no
guarantee that it will continue to work. Running obsolete stuff
is a risk.

Replacing what ain't broke also is a risk. Just ask all the companies
who are no more due to an attempt to "upgrade" to SAP.

Post by Arne Vajhøj
If the HW breaks can it be replaced.

In this particular case, emulators ...

Post by Arne Vajhøj
If something
changing breaks the SW can it be fixed.

That's a wide open topic. Anything can break. Anything can need
ongoing maintenance. You changed the oil in your auto lately? If not,
have then replaced the auto?

Post by Arne Vajhøj
If the people running
the stuff quits can they be replaced.

Sure, with people who know less, and may leave even quicker.

What about the risk of long term employees who know the existing system
and don't know the new stuff. Key on "long term", ie; loyal.

Post by Arne Vajhøj
Running on current HW,
supported SW and widely used SW reduces risk.

Perhaps, and perhaps not. WEENDOZE just did an update, and everything
quit working.

Post by Arne Vajhøj
it is July and you are checking your roof and you can see that
the beams are seriously weakened - it will collapse if it
gets 2 feet or more of snow.

Now it's broke, or ready to break. Of course it's time to repair or
replace. That is a different case than "it's just old".

Also, if the case is "checking your roof/app", and you see it will not
remain a solution, then changes are possible. But why before this?

We can argue this forever, but, I've seen too much of selfish interests
being put above the interests of the company.

Maybe I've just seen too much ...

:-)

[Jan-Erik Söderholm]

Post by Arne Vajhøj

Post by Jan-Erik Söderholm
And what say the sites still using/running VAXELN? A major kitchen
applience manufacturer in Sweden had multiple VAXELN system for
their assembly lines up to at least 3-4 years ago. Not sure of
the actual status today...

What about them? They must have licenses. And I assume
support on the involved SW and HW has ran out many years ago.
If I were in their shoes I would consider the platform a
business risk and create a roadmap to get on a supported
platform. But we all know that not everyone feel that way.
Arne

Last time I talked to the guy managing it (6 years ago) they were
looking at VAX emulators (ELN was/is supported by at least Stromasys,
at the time).

It sounded as these systems would live as long as the assembly site...

[Simon Clubley]

Post by Jan-Erik Söderholm
Last time I talked to the guy managing it (6 years ago) they were
looking at VAX emulators (ELN was/is supported by at least Stromasys,
at the time).
It sounded as these systems would live as long as the assembly site...

I wonder what language they used to write their VAXELN applications ?
Pascal, C or something else ?

BTW, I could never get the DEC C compiler to work with VAXELN (it failed
during linking IIRC), so unless there was some compatibility option
I was missing, it looks like you may have had to use VAX C with VAXELN,
even after DEC C became available.

VAXELN Pascal was supplied with VAXELN itself, but you were able to use
the native VMS VAX C compiler when using C to write VAXELN applications.

Simon.

[j***@yahoo.co.uk]

Post by Simon Clubley

Post by Jan-Erik Söderholm
Last time I talked to the guy managing it (6 years ago) they were
looking at VAX emulators (ELN was/is supported by at least Stromasys,
at the time).
It sounded as these systems would live as long as the assembly site...

I wonder what language they used to write their VAXELN applications ?
Pascal, C or something else ?
BTW, I could never get the DEC C compiler to work with VAXELN (it failed
during linking IIRC), so unless there was some compatibility option
I was missing, it looks like you may have had to use VAX C with VAXELN,
even after DEC C became available.
VAXELN Pascal was supplied with VAXELN itself, but you were able to use
the native VMS VAX C compiler when using C to write VAXELN applications.
Simon.
--
Walking destinations on a map are further away than they appear.

It's been a long time. For some of the official DEC history,
please consult the VAXELN SPDs over the years, and the
relevant VAXELN documentation.

With VAXELN, you run the host toolset on a VAX/VMS host, and the
generated system image on something that behaves like one of the
supported VAX boxes (or VAX system-on-module, e.g. rtVAX300, and
its VMEbus bigger brother, the KAV30).

As time went by, more languages were added, either officially or
unofficially. VAX C was probably first, Ada was obviously important
to some customers, some Fortran stuff of the time worked too. Refer
to SPD for more info. EDEBUG didn't understand these things so the
regular VAX/VMS debugger (as shipped with VMS V4 onward?) was used
instead, but in host/target style.

A regular contributor here may (or may not ;)) wish to comment on
whether proper VMS PASCAL (quite distinct from EPASCAL) worked or
was supported in the VAXELN environment.

If you'd asked around 25 years ago you could have had a better
answer but you might have needed a support contract or a sales
rep with a clue.

My recollection is that when DEC's Embedded+RealTime group got
Palmerised shortly before the turn of the century (ie sold off)
VAXELN software went with it, so I was a bit surprised a few
weeks ago when a reference was made (round here?) to VAXELN PAKs
being included in the hobbyist PAKs. ICBW.

[Robert A. Brooks]

Post by Simon Clubley
On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.
Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

The layered products (other than compilers, of which I have no knowledge)
were all common source for VAX, Alpha, and IA64.

Paul Anderson and I have largely scrubbed any VAX-specific stuff from the build
command procedures and MMS description files, and in some cases from the source,
in order to make things more readable. For FMS, for example, in making it work
on X86, there were a lot of conditionals where Alpha and IA64 took one branch,
and VAX took the other. In those cases, I removed the conditional check and the
VAX code, making it much easier to read.

I do not think we were given anything related to VAXeln.

[Simon Clubley]

Post by Robert A. Brooks

Post by Simon Clubley
On a more serious note, what I haven't seen discussed is the situation
regarding the VAX Layered Products.
Did you just get a core set of the VAX LP source code, such as some of the
compilers, or did you get pretty much everything ever produced for VAX
by DEC including products like VAXELN ?

The layered products (other than compilers, of which I have no knowledge)
were all common source for VAX, Alpha, and IA64.
Paul Anderson and I have largely scrubbed any VAX-specific stuff from the build
command procedures and MMS description files, and in some cases from the source,
in order to make things more readable. For FMS, for example, in making it work
on X86, there were a lot of conditionals where Alpha and IA64 took one branch,
and VAX took the other. In those cases, I removed the conditional check and the
VAX code, making it much easier to read.

Yes, that makes sense especially when you have determined that you will
_never_ be marketing a VSI version of VAX/VMS.

Post by Robert A. Brooks
I do not think we were given anything related to VAXeln.

Probably not a surprise actually. I asked the question because I was
wondering if you were given everything, including long-dead products
(in case you wanted to revive a specific product), or if you only got
the products which were active at the time of the handover.

Simon.

[Stephen Hoffman]

Post by Robert A. Brooks
Paul Anderson and I have largely scrubbed any VAX-specific stuff from
the build command procedures and MMS description files, and in some
cases from the source, in order to make things more readable.

Ditching 32-bit source code and 32-bit conditionals can make the source
code much simpler, particularly when the source code is working with
64-bit values.

Lots of limitations in the older 32-bit APIs, too. Particularly as the
same source code starts to adopt 64-bit operations and addressing.

Going to flat 64-bit addressing would simplify this further, though a
decade-long migration to flat 64-bit addressing would be exceptionally
fast.

[Simon Clubley]

Post by Stephen Hoffman

Post by Robert A. Brooks
Paul Anderson and I have largely scrubbed any VAX-specific stuff from
the build command procedures and MMS description files, and in some
cases from the source, in order to make things more readable.

Ditching 32-bit source code and 32-bit conditionals can make the source
code much simpler, particularly when the source code is working with
64-bit values.
Lots of limitations in the older 32-bit APIs, too. Particularly as the
same source code starts to adopt 64-bit operations and addressing.
Going to flat 64-bit addressing would simplify this further, though a
decade-long migration to flat 64-bit addressing would be exceptionally
fast.

If flat 64-bit addressing is ever going to happen, it's going to have
to come with some kind of a 32-bit addressing mode for existing code.

There's just too much going on at an unabstracted low level in VMS
code for flat 64-bit addressing to be viable by itself without any
other addressing modes.

You would also need some way of supporting the current 32-bit/64-bit
mixed addressing unless you outright discontinue such support.

P1 space would also be right in the way of a flat 64-bit addressing
mode so all the code which uses P1 space would have to be rewritten to
support flat 64-bit addresses because P1 space would have to be moved
well out of the way.

Simon.

[V***@SendSpamHere.ORG]

Post by Robert A. Brooks

HPE still owns VAX/VMS. VSI has no rights to VAX/VMS.

It's never pretty to see VSI-on-VSI violence, but I must disagree with my
esteemed colleague here.
Mike, we *do* have the rights (and the VAX master pack, including the
Emerald builds) to produce a VSI version of OpenVMS VAX.
We have chosen not to do that; we don't want Reagan to retire.

LOL

[David Goodwin]

Post by Michael Moroney
HPE still owns VAX/VMS. Unlike the Alpha/Itanium version, VSI did NOT get any
rights to VAX/VMS. Like it or not, HPE still owns VAX/VMS outright, for them
to ignore. And as pointed out, VSI has no interest in VAX/VMS.

They do not have the rights to any existing VAX release. But last I'd head VSI *do* have the rights to produce and license a new VAX release - there just isn't any money in doing so.

[Dave Froble]

Post by Michael Moroney

Post by Dave Froble

Post by Phillip Helbig (undress to reply)

Post by Dave Froble
Would VSI allow a VSI sponsored VAX/VMS Version (whatever), or do they
have some reason they do not want there to be a new VAX/VMS version?
Assume VSI hired Bob for $1 (donated by Dave) to build a new VSI version
of VAX/VMS, which would not cost them anything, no time (other than to
say Ok), and they would never be bothered by it's existence.
Assume some entity (call if DECUS, if possible) made the distribution
available, along with the required PAKs.
So, Ok, would Bob be willing and able to produce the new version? Would
someone provide him with the resources to do so? Would someone host the
distribution and PAKs and whatever else?

Why should VSI be involved at all? If I understand things correctly,
HPE could take that dollar. VSI isn't in the VAX picture at all.

You haven't been reading, or comprehending a damn thing.
HPe is out of the picture as far as VMs is concerned. By their own choice.
VSI is the entity that can produce new versions, and then distribute and
allow use of said new versions.
Any usage of VAX/VMS therefore must come from VSI.
VSI does not want to spend one penny on VAX.
VSI does not want to spend one minute on VAX.
Which part of the above do you not understand?

HPE still owns VAX/VMS. Unlike the Alpha/Itanium version, VSI did NOT get any
rights to VAX/VMS. Like it or not, HPE still owns VAX/VMS outright, for them
to ignore. And as pointed out, VSI has no interest in VAX/VMS.

Well Michael, you've made me do some work. Not my favorite thing.
You'll pay for that indiscretion ....

With the subject: Re: State of the OpenVMS hobbyist program?
On 11-20-2019
Rob Brooks wrote:

We have the VAX sources, and could, if we wanted to, build
a VSI version of OpenVMS VAX.

We are not going to do that.

Period. End of discussion.
--
-- Rob

So which is it, VSI could (but won't) build a VAX release, or, has no
right to do so?

:-)

[Bob Wilson]

Post by Stephen Hoffman
The OpenVMS source listings CD that David is referencing in the quoted
text above are expurgated listings. There are facilities and files
omitted from that. And components such as the checked-in compilers and
tools were not included in that. Nor the build procedures, for that
matter.

The official name for the "expurgated listings" were the "censored listings" ... and yes, as Steve says, there was a lot of "interesting stuff" was not included on them. When we made them as CD discs there were ~4-5 (fuzzy recollection, possibly fewer, definitely not more than 5). For whatever reason we stuck with CD discs for the Alpha listings kit after DVD discs became available (and which we used for the IA64 listings kits)...no comment.

In addition to the "censored listings" we made "uncensored listings" for the digital/compaq/hp support centers (at Colorado Springs, Valbonne and maybe a third one that I'm not remembering), but I think that they were still only listings.

n.b. Each facility on a result disk is a directory tree with a different sub-directory for sources, maps & listings, build procedures specific to that facility, object files/libraries & images produced by that facility build, etc. ... much of which did *not* get included in either the censored or uncensored discs).

The uncensored set was 10-12 discs. Listings that contained licensed source code was also "censored".

[Bob Wilson]

Post by Stephen Hoffman
Approximately nobody was working with the 32-bit build environment
after V7.3, save for building incremental fixes. Source code control
was still active, as were targeted builds for patches. I don't recall
if there were any full builds after V7.3 shipped, but there would not
have been very many of those.

There were in fact post-V7.3 full VAX VMS system builds done. It was never explicitly stated that there would no longer be any VAX VMS releases, so....the build & release team has to make sure that at least the build infrastructure works even though the output is totally broken. We actually were down to "quarterly builds" for that reason.

Also *many* checkins were done [by conscientious engineers who maintained facilities that were common between the VAX and Alpha architectures...they/we never got the word to stop] (I got emails for each one, so I can assure you that there were non-remedial post-V7.3 checkins).

[Michael Moroney]

Post by Bob Wilson
There were in fact post-V7.3 full VAX VMS system builds done. It was never
explicitly stated that there would no longer be any VAX VMS releases, so....
the build & release team has to make sure that at least the build infrastructure
works even though the output is totally broken. We actually were down to
"quarterly builds" for that reason.
Also *many* checkins were done [by conscientious engineers who maintained
facilities that were common between the VAX and Alpha architectures...they/we
never got the word to stop] (I got emails for each one, so I can assure you
that there were non-remedial post-V7.3 checkins).

Emerald, correct? Supposed to be V7.4?

Wasn't that something that got cancelled as 8.x started to come out, or as
part of the Alphacide? [killing off VAX as well] Or was it always unofficial?

[Terry Kennedy]

Post by Dave Froble

Post by Bill Gunshannon

Post by Craig A. Berry

Post by Bill Gunshannon

On Friday, July 17, 2020 at 12:41:58 PM UTC-4, Phillip Helbig

Post by Phillip Helbig (undress to reply)

Post by Alice Wyan
If I understand the situation correctly, HPE is completely dropping
support for VAX VMS, but the rights haven't been transferred to VSI.
This means starting next year VMS on the VAX is essentially abandoned.

Right. I can understand VSI having little interest in it; it surely
couldn't be justified financially.

Post by Alice Wyan
If HPE is no longer going to be making money out of it, what would be
stopping them from selling it/give the rights away to, say, a hobbyist
collective that could be set up to preserve this system?

Nothing, except that they figure that it is not worth their time.

Post by Alice Wyan
I guess there'd be quite a legal mess of rights behind the old code,
but...

I'm sure that they have a lot of experience with that, and the situation
wouldn't be that much different than Alpha or Itanium.

Post by Alice Wyan
would it be a doable thing?

Certainly.

I have said several times, to several people, in several forums: The
day you ask me to starting making VAX compilers again is the day
we'll start planning my retirement party. I ain't got no time for
that stuff. The thought of the VAX VCG and PL/1 (much of the VCG is
written in PL/1) is a hard NO. I will use my safeword on that one.

What happened to the compilers that were used to build VAX
versions in the past? I would have thought there was one
big archive with everything VAX related in it. Were they
really so incompetent that they lost some of it? I would
have expected that all it would really take for someone new
to build a VAX version of VMS today would be to have the
archive and a machine (today, probably an emulated system)
to load it on and run the build process.

No one said anything was lost. The context was the prospect of having
VSI produce a VAX release, which would be necessary before they could
issue licenses (hobbyist or otherwise) for VAX, but which they have said
numerous times they aren't going to do. In that context, John is
obviously talking about *maintaining* the VCG compilers, which he would
have to do if VSI were producing VAX releases. Or not maintaining them,
since he would quit first.

VAX VMS isn't maintained now. Hasn't been for, I don't klnow, a
decade maybe. No one is asking for it to be maintained. The
assumption was (at least on my part) that the archive of the
system used to create the last release of VAX VMS still existed.
If that is the case all that should need to be done is to load
it on a system (probably emulated and thus likely to be much faster
than the system last used to build it) and run the build scripts.
I always thought VMS engineering was professional enough (at least
when it was still done by people like Hoff) that the system was
smooth and maybe even documented.
If desired they could change the startup banner to reflect VSI
taking over, but no change to any of the code would be necessary.

Post by Craig A. Berry
Now, if some bored computer science students with nothing to do during
the pandemic would update llvm-alpha and produce an llvm-vax code
generator, everything would be gravy :-). Except John would probably
still quit if he had to make the LLVM-based compilers with the GEM
emulation target VAX since the GEM-based compilers are likely full of
post-VAX assumptions.

If they weren't the compilers used in the past, why would you need
them now for a "one-off" run?
bill

I'd think that nothing new would be required. So John might be safe.
However I do believe that both Clair and Steve have touched on this
The build was spread over multiple systems
The build was not 100% automated (big issue)
The build included things beyond compiling and linking
The build instructions might be lost

Some old timers may remember when the VMS microfiche listings grew to more than 999 pages, and the tool used to prepare them for production was a Fortran program with an I3 format spec. This resulted in the index sheets having a lot of "***" instead of the correct page reference. This went on for several VMS versions before someone representing some major customers managed to get DEC's attention and DEC agreed to produce corrected listing sets for the affected releases. However, they had a huge amount of difficulty as they were trying to rebuild identical binaries with different compiler versions than were originally used. It took quite some time and a formal byte-by-byte comparison of the new builds to ensure that the binary code was indeed identical to the releases that shipped with bad listings, and then re-issuing listings with correct page numbers. The replacement listing fiche sets for all releases ran to something like 18" deep. This process cost DEC a lot of time and money, but they were obligated to do it, so they did.

Based on that, I doubt that anyone attempting to rebuild VAX/VMS from source will get anything close to the exact binaries. These divergent binaries may have new bugs based on the different toolchain, etc. I fully support VSI's stated intention to never build a VAX release. Of course, if a sufficient number of commercial customers come along waving piles of cash, there is an infinitesimal chance that VSI would look into it. You may recall that they originally said they wouldn't do Alpha releases, but eventually changed their mind because there were actual paying customers who had not migrated from Alpha to IA64. So they did a test build to see if they could, and AFAIK that is now a supported product offering from them.

But I can't imagine there are enough (or any) commercial users still on VAX who would be willing to pay enough for VSI to even think about a VAX build. And as I mentioned before, VAX/VMS is so far behind the current Alpha/IA64 versions that it is likely impossible to produce a "cluster compatibility kit" that would let it coexist in a cluster with current VSI Alpha/IA64 VMS, let alone x86 VMS, at least without crippling limitations that would make it essentially useless. For example, did VAX ever get ODS-5 or large disk support?

So I don't think it is reasonable to think that anything for VAX will be forthcoming from VSI. It seems your only hope for hobbyist VAX systems to continue running VMS after the last hobbyist PAKs expire is to convince HP to make lifetime PAKs available as a nice gesture to a community that they essentially abandoned. It would be interesting to see if HP is actually capable of selling VAX licenses and/or handling license transfers for whatever fee they quote is. I expect it will be a long and unproductive experience for anyone who actually tries to buy these from HP.

[Simon Clubley]

Post by John Reagan
I have said several times, to several people, in several forums: The day
you ask me to starting making VAX compilers again is the day we'll start
planning my retirement party. I ain't got no time for that stuff. The
thought of the VAX VCG and PL/1 (much of the VCG is written in PL/1) is a
hard NO. I will use my safeword on that one.

Given how nice the VAX architecture itself actually was as a compiler
target, what made the compilers so horrible to work with ?

Or is it the PL/1 bit you don't like ? :-)

Simon.

[John Reagan]

Post by Simon Clubley

Post by John Reagan
I have said several times, to several people, in several forums: The day
you ask me to starting making VAX compilers again is the day we'll start
planning my retirement party. I ain't got no time for that stuff. The
thought of the VAX VCG and PL/1 (much of the VCG is written in PL/1) is a
hard NO. I will use my safeword on that one.

Given how nice the VAX architecture itself actually was as a compiler
target, what made the compilers so horrible to work with ?
Or is it the PL/1 bit you don't like ? :-)
Simon.

Unlike Alpha and beyond where all the compilers use a common backend, the VAX product set was all over the. VAX BASIC, COBOL, Pascal, Fortran, and BLISS each have their own code generator. Nothing in common beyond being written in BLISS.

C, C++, Ada, PL/1, SCAN all "used" the VCG but in spite of the COMMON word, there were several clones of the VCG each with its own language variant features. So you can argue there is somewhere between 1 and 5 VCGs.

And it was cloned yet again for the VAXELN EPASCAL compiler. It shares nothing with the VAX/VMS Pascal compiler.

The PL/1 in the Freiburghouse frontend and additional optimization phases has some limitations. In order to save space, many of the tree structures didn't have pointers but just 16-bit indices that went through a table of addresses. It was quite common to exceed this 64K max flow nodes during large compilations. My recollection is that the compiler silently fell back to limited optimization setting.

I don't dislike PL/1. We can argue at length about the meaning of "/" vs "div" on certain datatypes. And at times, it feels just as bad as C++ for a human trying to divine what a piece of code was going to mean to the compiler.

For the non-VCG backends, I think the quality is pretty good. The VCG on the other hand seemed to be quite fragile (I never worked on on the VCG but we all sat at the same lunch table and shared stories - there are a few ex engineers who read c.o.v now and them and I'm sure they'll send me email to correct me). Do HELP CC on the VAX and look at all the optimizer knobs that exist (and there are many undocumented knobs too). They didn't expose all those settings just for fun, they were there so you can start turning them off to avoid optimizer/backend bugs.

[Simon Clubley]

Post by John Reagan
For the non-VCG backends, I think the quality is pretty good. The VCG on the other hand seemed to be quite fragile (I never worked on on the VCG but we all sat at the same lunch table and shared stories - there are a few ex engineers who read c.o.v now and them and I'm sure they'll send me email to correct me). Do HELP CC on the VAX and look at all the optimizer knobs that exist (and there are many undocumented knobs too). They didn't expose all those settings just for fun, they were there so you can start turning them off to avoid optimizer/backend bugs.

I understand now. :-)

Thanks, John.

Simon.

[Terry Kennedy]

I would expect to see someone pull a rabbit full of non-expiring VAX hobbyist licenses out of a hat sometime shortly before or after the HP final expiration date. There are a large number of people capable of easily doing this. The issue becomes how someone anonymously and untraceably makes these available to the community.

I have no idea if this is still the current status, but it is the latest I could find on copyright.gov: https://www.copyright.gov/1201/docs/librarian_statement_01.html

Note exemption number 3: "Computer programs and video games distributed in formats that have become obsolete and which require the original media or hardware as a condition of access." That may be applicable to the current situation.

[Dave Froble]

Post by Terry Kennedy
I would expect to see someone pull a rabbit full of non-expiring VAX hobbyist licenses out of a hat sometime shortly before or after the HP final expiration date. There are a large number of people capable of easily doing this. The issue becomes how someone anonymously and untraceably makes these available to the community.
I have no idea if this is still the current status, but it is the latest I could find on copyright.gov: https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games distributed in formats that have become obsolete and which require the original media or hardware as a condition of access." That may be applicable to the current situation.

Interesting.

Note that the exemption provides coverage of one attempting the use the
exemption, and, if there is objection, the case would be adjudicated.

Now who thinks HPe will give a damn and spend one red cent on any legal
action?

Rather than a "rabbit full", why not a single license usable by anyone?

I think Terry deserves an "atta-boy" for this information.

[John H. Reinhardt]

Now who thinks HPe will give a damn and spend one red cent on any legal action?
Rather than a "rabbit full", why not a single license usable by anyone?

Because, as you should know, there is no one license PAK for everything. VAX/VMS needs a PAK. x users or unlimited users needs another PAK. DECnet needs a PAK. UCX/TCPIP needs a PAK. VAXcluster needs a PAK. Volume Shadowing needs a PAK. BASIC needs a PAK. Cobol needs a PAK. Fortran needs a PAK. Pascal needs a PAK. Get where I'm going? Maybe not the 107 PAKS that came with the Hobbyist bundle (Does anyone really need HANZI DW-Motif?) but still a goodly number of different PAKs will be required.

I think Terry deserves an "atta-boy" for this information.

[Dave Froble]

Post by John H. Reinhardt

Now who thinks HPe will give a damn and spend one red cent on any legal action?
Rather than a "rabbit full", why not a single license usable by anyone?

Because, as you should know, there is no one license PAK for
everything.

Yes, I'm aware of that. But an appropriate PAK for each product should
work on every VAX. So yeah, a bunch of PAKs, but only one for each
product. Should not need more than that.

[Chris Scheers]

Post by John H. Reinhardt

Now who thinks HPe will give a damn and spend one red cent on any legal action?
Rather than a "rabbit full", why not a single license usable by anyone?

Because, as you should know, there is no one license PAK for
everything. VAX/VMS needs a PAK. x users or unlimited users needs
another PAK. DECnet needs a PAK. UCX/TCPIP needs a PAK. VAXcluster
needs a PAK. Volume Shadowing needs a PAK. BASIC needs a PAK. Cobol
needs a PAK. Fortran needs a PAK. Pascal needs a PAK. Get where I'm
going? Maybe not the 107 PAKS that came with the Hobbyist bundle (Does
anyone really need HANZI DW-Motif?) but still a goodly number of
different PAKs will be required.

I think Terry deserves an "atta-boy" for this information.

FWIW: The VAX Portfolio PAK covers many (most?) of the layered products.

[Hans Bachner]

Post by Chris Scheers

Post by John H. Reinhardt

Now who thinks HPe will give a damn and spend one red cent on any legal action?
Rather than a "rabbit full", why not a single license usable by anyone?

Because, as you should know, there is no one license PAK for
everything.  VAX/VMS needs a PAK.  x users or unlimited users needs
another PAK.  DECnet needs a PAK. UCX/TCPIP needs a PAK.  VAXcluster
needs a PAK.  Volume Shadowing needs a PAK.  BASIC needs a PAK.  Cobol
needs a PAK.  Fortran needs a PAK. Pascal needs a PAK.  Get where I'm
going?  Maybe not the 107 PAKS that came with the Hobbyist bundle
(Does anyone really need HANZI DW-Motif?) but still a goodly number of
different PAKs will be required.

I think Terry deserves an "atta-boy" for this information.

FWIW: The VAX Portfolio PAK covers many (most?) of the layered products.

I'm unaware of any "VAX Portfolio PAK" - what is this?

The only PAKs I know that cover multiple products are the
NET-APP-SUP-nnn PAKs whoch include things like DECnet, TCP/IP,
DECwindows, VMScluster and others depending on the value of "nnn".

Hans.

[Alice Wyan]

I'm assuming it refers to the hobbyist PAKs, which include quite a lot of products

Post by Hans Bachner
I'm unaware of any "VAX Portfolio PAK" - what is this?
The only PAKs I know that cover multiple products are the
NET-APP-SUP-nnn PAKs whoch include things like DECnet, TCP/IP,
DECwindows, VMScluster and others depending on the value of "nnn".
Hans.

[Chris Scheers]

Post by Hans Bachner

Post by Chris Scheers

Post by John H. Reinhardt

Now who thinks HPe will give a damn and spend one red cent on any legal action?
Rather than a "rabbit full", why not a single license usable by anyone?

Because, as you should know, there is no one license PAK for
everything. VAX/VMS needs a PAK. x users or unlimited users needs
another PAK. DECnet needs a PAK. UCX/TCPIP needs a PAK. VAXcluster
needs a PAK. Volume Shadowing needs a PAK. BASIC needs a PAK.
Cobol needs a PAK. Fortran needs a PAK. Pascal needs a PAK. Get
where I'm going? Maybe not the 107 PAKS that came with the Hobbyist
bundle (Does anyone really need HANZI DW-Motif?) but still a goodly
number of different PAKs will be required.

I think Terry deserves an "atta-boy" for this information.

FWIW: The VAX Portfolio PAK covers many (most?) of the layered products.

I'm unaware of any "VAX Portfolio PAK" - what is this?
The only PAKs I know that cover multiple products are the
NET-APP-SUP-nnn PAKs whoch include things like DECnet, TCP/IP,
DECwindows, VMScluster and others depending on the value of "nnn".

I know of three "Portfolio" PAKs:

BASE-PROG-DEV-PORTFOLIO
EXT-PROG-DEV-PORTFOLIO
PROG-DEV-RT-PORTFOLIO

These all seem to be for programing/development.

No SIPs (VAXcluster, DECwindows, DECNET, etc.) are included.

The RT PAK provides runtime licenses for various products. For example,
ACMS, NOTES, RALLY, RDB, etc.

EXT is a superset of BASE. These provide access to various development
products such as compilers, VAXELN, SCAN, etc.

[Hans Bachner]

Post by Chris Scheers

Post by Hans Bachner

Post by Chris Scheers

Post by John H. Reinhardt

Now who thinks HPe will give a damn and spend one red cent on any legal action?
Rather than a "rabbit full", why not a single license usable by anyone?

Because, as you should know, there is no one license PAK for
everything.  VAX/VMS needs a PAK.  x users or unlimited users needs
another PAK.  DECnet needs a PAK. UCX/TCPIP needs a PAK.  VAXcluster
needs a PAK.  Volume Shadowing needs a PAK.  BASIC needs a PAK.
Cobol needs a PAK.  Fortran needs a PAK. Pascal needs a PAK.  Get
where I'm going?  Maybe not the 107 PAKS that came with the Hobbyist
bundle (Does anyone really need HANZI DW-Motif?) but still a goodly
number of different PAKs will be required.

I think Terry deserves an "atta-boy" for this information.

FWIW: The VAX Portfolio PAK covers many (most?) of the layered products.

I'm unaware of any "VAX Portfolio PAK" - what is this?
The only PAKs I know that cover multiple products are the
NET-APP-SUP-nnn PAKs whoch include things like DECnet, TCP/IP,
DECwindows, VMScluster and others depending on the value of "nnn".

BASE-PROG-DEV-PORTFOLIO
EXT-PROG-DEV-PORTFOLIO
PROG-DEV-RT-PORTFOLIO
These all seem to be for programing/development.
No SIPs (VAXcluster, DECwindows, DECNET, etc.) are included.
The RT PAK provides runtime licenses for various products.  For example,
ACMS, NOTES, RALLY, RDB, etc.
EXT is a superset of BASE.  These provide access to various development
products such as compilers, VAXELN, SCAN, etc.

Thanks for sharing the details - I've never heard of those before.

Hans.

[Terry Kennedy]

Post by Dave Froble
Rather than a "rabbit full", why not a single license usable by anyone?

I was thinking that someone would create a .COM file using the same set of PAKs that were included in the most recent HP hobbyist PAK bundle (plus the few additions mentioned here that were available by request), just with no expiration date. Those would be usable by anyone. It is too bad that DEC never had an /OPTIONS=(VAX_ONLY) to prevent misuse of this set of PAKs on Alpha. There is a VAX_ALPHA option, but not all products bother checking for that, so some will run on VAX or Alpha anyway, AFAIK (I have not tried any of the PAKs from a HP VAX Hobbyist kit on an Alpha). I think IA64 compliance enforcement is better controlled as those products were ported and maintained (at least sort-of) much more recently.

Post by Dave Froble
I think Terry deserves an "atta-boy" for this information.

Just pointing out one possible solution. I think it would be the most elegant. There are many known LMF hacks, including ones that will allow REGISTER operations with invalid checksums (since the register operation has to compute the correct checksum, the patch just causes it to insert the correct checksum into the database instead of rejecting the incorrect one) and a number of ways to disable run-time checking of license validity. Some old-timers may remember the "Screw LMF" T Shirt from a long-ago DECUS Symposium which had a 7-line or so patch to disable checks.

But I think that issuing "bogus" licenses for the same set of products listed in the most recent Hobbyist PAK collection shows an attempt to comply with the intentions of HP and the Librarian of Congress as to what products were available to Hobbyists, instead of an "anything goes" which would likely include 3rd-party software, some of which might still be supported (or at least sold).

[Bill Gunshannon]

Post by Terry Kennedy
But I think that issuing "bogus" licenses for the same set of products listed in the most recent Hobbyist PAK collection shows an attempt to comply with the intentions of HP and the Librarian of Congress as to what products were available to Hobbyists, instead of an "anything goes" which would likely include 3rd-party software, some of which might still be supported (or at least sold).

Hi Terry.

Not meaning to sound pedantic, but, name one product for VMS on
a VAX that is still for sale, much less supported. :-)

bill

[Dave Froble]

Post by Bill Gunshannon

Post by Terry Kennedy
But I think that issuing "bogus" licenses for the same set of products
listed in the most recent Hobbyist PAK collection shows an attempt to
comply with the intentions of HP and the Librarian of Congress as to
what products were available to Hobbyists, instead of an "anything
goes" which would likely include 3rd-party software, some of which
might still be supported (or at least sold).

Hi Terry.
Not meaning to sound pedantic, but, name one product for VMS on
a VAX that is still for sale, much less supported. :-)
bill

Well, with the main purpose of sticking needles in my "Bill doll", I
could say that all my VAX/VMS products are still for sale, and
supported. Just not marketed.

Wanna buy some?

:-)

[Terry Kennedy]

Post by Bill Gunshannon
Hi Terry.
Not meaning to sound pedantic, but, name one product for VMS on
a VAX that is still for sale, much less supported. :-)

Will MultiNet suffice? 8-}
http://process.com/products/multinet/index.html

[Alice Wyan]

Post by Bill Gunshannon
Not meaning to sound pedantic, but, name one product for VMS on
a VAX that is still for sale, much less supported. :-)

Process still sells TCPWARE and the other network kits for the VAX – they are also available under the hobbyist program, too.

[Simon Clubley]

Post by Dave Froble
I think Terry deserves an "atta-boy" for this information.

No he doesn't. He does however deserve a "he's in danger of seriously
annoying VSI instead" type warning.

Simon.

[Dave Froble]

Post by Simon Clubley

Post by Dave Froble
I think Terry deserves an "atta-boy" for this information.

No he doesn't. He does however deserve a "he's in danger of seriously
annoying VSI instead" type warning.
Simon.

Please explain how using an exemption in the DMCA for old products would
annoy VSI?

Do understand, should HPe object to the usage of such an exemption, it
will be the US government they are having an issue with, not the
individual user of the exemption.

[Simon Clubley]

Post by Terry Kennedy
I would expect to see someone pull a rabbit full of non-expiring VAX
hobbyist licenses out of a hat sometime shortly before or after the HP
final expiration date. There are a large number of people capable of easily
doing this. The issue becomes how someone anonymously and untraceably makes
these available to the community.

I'm sorry Terry, but to even suggest this is badly irresponsible and outright
wrong.

Post by Terry Kennedy
I have no idea if this is still the current status, but it is the latest
https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games distributed
in formats that have become obsolete and which require the original media
or hardware as a condition of access." That may be applicable to the
current situation.

No it isn't. You have no legal right to run the VAX/VMS distributions
other than the rights granted to you on a temporary basis by its current
owners.

Your argument is just another take on the abandonware argument and the
abandonware argument has been shown to have no basis in law.

If you truly believed differently, you wouldn't be speaking above about
anonymously and untraceably creating licences.

Even if you don't consider it from the ethical/legal point of view then
consider it from the practical point of view:

What the hell do you think certain people at VSI are going to think when
they see this discussion while trying to decide whether to launch a
hobbyist program and in what form ?

You have no rights to free access to VMS other than the rights granted
to you by HPE and now VSI. It makes sense for VSI to offer such access
as a way of boosting VMS use, but not if people think they can take such
access and use it for whatever they want and forever.

Seriously people, knock it off. VAX/VMS access is probably dead as of
1-Jan-2022 and unless you knock this off, so might be hobbyist access
to the other architectures that VMS runs on.

If you don't care about the ethical or legal points of view, then care
about that.

Simon.

[Arne Vajhøj]

Post by Simon Clubley

Post by Terry Kennedy
I have no idea if this is still the current status, but it is the latest
https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games distributed
in formats that have become obsolete and which require the original media
or hardware as a condition of access." That may be applicable to the
current situation.

No it isn't. You have no legal right to run the VAX/VMS distributions
other than the rights granted to you on a temporary basis by its current
owners.
Your argument is just another take on the abandonware argument and the
abandonware argument has been shown to have no basis in law.

The link is actually not about abandonware. But about circumventing
technical license enforcement in case of it requiring obsolete
media/hardware.

Abandonware is not a concept in US law, but it is a concept in EU law
(Orphan Works Directive). And it does not apply to VMS at all - it
applies only to cases where copyright holder cannot be found and it
does not apply to software in general.

Arne

[Simon Clubley]

Post by Arne Vajhøj

Post by Simon Clubley

Post by Terry Kennedy
I have no idea if this is still the current status, but it is the latest
https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games distributed
in formats that have become obsolete and which require the original media
or hardware as a condition of access." That may be applicable to the
current situation.

No it isn't. You have no legal right to run the VAX/VMS distributions
other than the rights granted to you on a temporary basis by its current
owners.
Your argument is just another take on the abandonware argument and the
abandonware argument has been shown to have no basis in law.

The link is actually not about abandonware. But about circumventing
technical license enforcement in case of it requiring obsolete
media/hardware.

And that is exactly the point I was making. Terry was trying to twist
the meaning of that section into something that he could use to make
the same kind of arguments that the abandonware people make.

That's why I pointed out that he (and other hobbyists) had no inherent
right to run VAX/VMS other than on a temporary basis as granted by HPE.

Post by Arne Vajhøj
Abandonware is not a concept in US law, but it is a concept in EU law
(Orphan Works Directive). And it does not apply to VMS at all - it
applies only to cases where copyright holder cannot be found and it
does not apply to software in general.

Thanks for reminding me about the Orphan Works Directive. I had forgotten
about that.

Simon.

[Arne Vajhøj]

Post by Terry Kennedy
I would expect to see someone pull a rabbit full of non-expiring VAX
hobbyist licenses out of a hat sometime shortly before or after the
HP final expiration date. There are a large number of people capable
of easily doing this. The issue becomes how someone anonymously and
untraceably makes these available to the community.

And illegal.

Post by Terry Kennedy
I have no idea if this is still the current status, but it is the
https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games
distributed in formats that have become obsolete and which require
the original media or hardware as a condition of access." That may be
applicable to the current situation.

I don't think that says what you think it says.

It says that it is legal to circumvent technical limitations
if those require obsolete media/hardware.

So if LMF on VAX checked the presence of original VMS 9 track
tape in a tape drive and you legally have a VMS license but your
VAX does not have a 9 track tape, then you may legally
patch LMF to skip that tape check (assuming we can agree
that 9 track tape is obsolete).

VMS does not do anything like that, so it is not relevant.

Arne

[Terry Kennedy]

Post by Arne Vajhøj

Post by Terry Kennedy
I would expect to see someone pull a rabbit full of non-expiring VAX
hobbyist licenses out of a hat sometime shortly before or after the
HP final expiration date. There are a large number of people capable
of easily doing this. The issue becomes how someone anonymously and
untraceably makes these available to the community.

And illegal.

Post by Terry Kennedy
I have no idea if this is still the current status, but it is the
https://www.copyright.gov/1201/docs/librarian_statement_01.html
Note exemption number 3: "Computer programs and video games
distributed in formats that have become obsolete and which require
the original media or hardware as a condition of access." That may be
applicable to the current situation.

I don't think that says what you think it says.

I am not a lawyer. I just posted the first result from a US government site that seemed relevant to what I had heard several years ago, the first time that exception came around. If you don't think it is relevant, then lobby for a change to meet your definition the next time it comes up for renewal (happens every 3 years).

And I am NOT trying to "annoy" VSI. In fact, I have never communicated with them about the VAX situation, although I did offer them money for a non-commercial/hobbyist type license, and they said at the time that they had not even started discussing it among themselves.

I do note, however that:
1) They have no interest/ability/legal standing to do anything about VAX/VMS.
2) Their commercial license for Alpha is a 'everything and the kitchen sink' license for everything (confirmed with several of their real customers). IA64 is still individual licenses, AFAIK, but that is a platform HP is (or was- see the "no answer to a hardware support call" post in this group) still selling/supporting.
3) I believe I remember VSI saying there would never be a "cluster compatibility kit" for VAX/VMS both due to its age and their inability to release patches for VMS releases they didn't build themselves.
4) I also think I remember that at one time VSI said that LMF might not be the licensing implementation on x86 VMS.

However, since enough of you feel that this is a danger to whatever hobbyist program VSI might eventually offer, feel free to sacrifice your VAXen on the altar of your choice. You can always go visit a real VAX with non expiring licenses (granted by HP) at your local computer museum. Oh, wait... I only know of 3- the LCM, which may be a casualty of the pandemic, the CHM which does not exhibit a running VAX, or the LSSM (where I do my best to keep their VAXen running).

I've said my piece now. Maybe someone will do what I mentioned at the beginning of all this and issue non-expiring VAX PAKs (HP or someone else like the VLF) but it won't be (and wouldn't have been) me.

[Bill Gunshannon]

Post by Arne Vajhøj
So if LMF on VAX checked the presence of original VMS 9 track
tape in a tape drive and you legally have a VMS license but your
VAX does not have a 9 track tape, then you may legally
patch LMF to skip that tape check (assuming we can agree
that 9 track tape is obsolete).

Why would anyone assume that? I have a quite modern SCSI 9 track
that works fine on DEC Hardware, Sun Hardware, PC's and pretty much
everything else I have had reason to try it on.

May not be as common as it once was but there is still a lot (and
I mean a real lot) of archived 9track data out there.

bill

[Arne Vajhøj]

Post by Arne Vajhøj
So if LMF on VAX checked the presence of original VMS 9 track
tape in a tape drive and you legally have a VMS license but your
VAX does not have a 9 track tape, then you may legally
patch LMF to skip that tape check (assuming we can agree
that 9 track tape is obsolete).

Why would anyone assume that?  I have a quite modern SCSI 9 track
that works fine on DEC Hardware, Sun Hardware, PC's and pretty much
everything else I have had reason to try it on.
May not be as common as it once was

Always a bit funky to discuss a made up scenario.

But I think it is rare enough today that it may qualify
as obsolete in the context.

but there is still a lot (and
I mean a real lot) of archived 9track data out there.

I believe that.

I also suspect that the actual recovery rate may turn
out somewhat less than 100% if attempted to read them all.
Bad tapes, bad tape drives etc..

Arne

[Rod Regier]

I've gotten some non VAX/VMS license prices out of Jon Fellman.
One of my customers successfully purchased permanent BOE and DFG licenses for OpenVMS/I64 from him.

He's legally reselling licenses that were used on HP(E) leases that have concluded.

I doubt any VAX/VMS licenses are available from terminated leases.

Apparently if you ask for licenses he doesn't have in hand
he just doesn't bother to answer, based on my experience.
Curious way of doing business, but he has a monopoly.

[Simon Clubley]

Post by Rod Regier
I've gotten some non VAX/VMS license prices out of Jon Fellman.
One of my customers successfully purchased permanent BOE and DFG licenses for OpenVMS/I64 from him.
He's legally reselling licenses that were used on HP(E) leases that have concluded.
I doubt any VAX/VMS licenses are available from terminated leases.

I don't understand. This is either a HP or HPE employee selling licences
for a HPE product. Why doesn't HPE just issue new VAX/VMS licences and
take the customer's money, while making it clear the customer is buying
the licence as-is without support ?

Post by Rod Regier
Apparently if you ask for licenses he doesn't have in hand
he just doesn't bother to answer, based on my experience.

Charming.

Post by Rod Regier
Curious way of doing business, but he has a monopoly.

But I don't understand _why_ he has a monopoly. It's free money for HPE
if they just issue new VAX/VMS licences (and without any support overheads)
on demand.

Someone posted the link to the licence transfer page the other day.
Why doesn't HPE have a similar process for creating and selling new
VAX/VMS licences ?

Simon.

[abrsvc]

The location in Andover Ma is what is called the "Technology Renewal Center" where HP takes in hardware etc. from clients that are upgrading to newer hardware. This used hardware is verified and certified and then resold. There is software that is acquired as well which is where these licenses are soruced. There is no license generation software at that site. Since the software is owned by the companies doing the upgrade, a transfer of license is required and is what is being offered.