VAX VMS going forward

Alice Wyan

unread,

Jul 17, 2020, 7:42:09 AM7/17/20

to

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

unread,

Jul 17, 2020, 8:21:39 AM7/17/20

to

Alice Wyan <fin...@gmail.com> wrote:
>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
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

Simon Clubley

unread,

Jul 17, 2020, 8:29:47 AM7/17/20

to

On 2020-07-17, Alice Wyan <fin...@gmail.com> wrote:
> 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.)

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

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

John E. Malmberg

unread,

Jul 17, 2020, 8:35:50 AM7/17/20

to

On 7/17/2020 6:42 AM, Alice Wyan wrote:
> 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.

> 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

Arne Vajhøj

unread,

Jul 17, 2020, 10:46:13 AM7/17/20

to

On 7/17/2020 7:42 AM, Alice Wyan wrote:
> 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.

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

unread,

Jul 17, 2020, 12:41:58 PM7/17/20

to

In article <9513122f-5615-4d7c...@googlegroups.com>,
Alice Wyan <fin...@gmail.comwrites:

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

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

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

> would it be a doable thing?

Certainly.

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

Phillip Helbig (undress to reply)

unread,

Jul 17, 2020, 12:44:14 PM7/17/20

to

In article <res5jp$4kn$1...@dont-email.me>, Simon Clubley

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

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

Phillip Helbig (undress to reply)

unread,

Jul 17, 2020, 12:45:33 PM7/17/20

to

In article <res5v5$cbr$1...@dont-email.me>, "John E. Malmberg"

<wb8...@qsl.net_work> writes:

> On 7/17/2020 6:42 AM, Alice Wyan wrote:
> > 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.

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

What sort of license does that have?

Simon Clubley

unread,

Jul 17, 2020, 1:15:25 PM7/17/20

to

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.

John Reagan

unread,

Jul 17, 2020, 1:35:34 PM7/17/20

to

On Friday, July 17, 2020 at 12:41:58 PM UTC-4, Phillip Helbig (undress to reply) wrote:
> In article <9513122f-5615-4d7c...@googlegroups.com>,
> Alice Wyan <fin...@gmail.comwrites:
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.

John Dallman

unread,

Jul 17, 2020, 1:57:34 PM7/17/20

to

In article <reskgq$aup$2...@gioia.aioe.org>, hel...@asclothestro.multivax.de

(Phillip Helbig (undress to reply)) wrote:

> 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

Terry Kennedy

unread,

Jul 17, 2020, 4:05:56 PM7/17/20

to

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.

Phillip Helbig (undress to reply)

unread,

Jul 17, 2020, 4:41:26 PM7/17/20

to

John Reagan <xyzz...@gmail.com> writes:

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

Phillip Helbig (undress to reply)

unread,

Jul 17, 2020, 4:46:03 PM7/17/20

to

In article <memo.2020071...@jgd.cix.co.uk>, j...@cix.co.uk

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.

Bob Eager

unread,

Jul 17, 2020, 5:07:40 PM7/17/20

to

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

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

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

Bill Gunshannon

unread,

Jul 17, 2020, 6:26:42 PM7/17/20

to

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

Bill Gunshannon

unread,

Jul 17, 2020, 6:29:28 PM7/17/20

to

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

bill

Dave Froble

unread,

Jul 17, 2020, 6:47:19 PM7/17/20

to

On 7/17/2020 8:35 AM, John E. Malmberg wrote:

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

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.

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

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

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

Dave Froble

unread,

Jul 17, 2020, 7:02:36 PM7/17/20

to

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.

Robert A. Brooks

unread,

Jul 17, 2020, 7:39:28 PM7/17/20

to

On 7/17/2020 6:46 PM, Dave Froble wrote:

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

--

-- Rob

John H. Reinhardt

unread,

Jul 17, 2020, 10:54:45 PM7/17/20

to

On 7/17/2020 6:02 PM, Dave Froble wrote:

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

--

John H. Reinhardt

Phillip Helbig (undress to reply)

unread,

Jul 18, 2020, 2:03:45 AM7/18/20

to

In article <ret9pk$9nd$1...@dont-email.me>, Dave Froble

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

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

Terry Kennedy

unread,

Jul 18, 2020, 2:10:46 AM7/18/20

to

On Friday, July 17, 2020 at 7:02:36 PM UTC-4, Dave Froble wrote:
> 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.

> 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

unread,

Jul 18, 2020, 7:57:04 AM7/18/20

to

On 7/18/20 2:10 AM, Terry Kennedy wrote:
>
>
> 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

unread,

Jul 18, 2020, 10:28:19 AM7/18/20

to

On 7/17/2020 10:54 PM, John H. Reinhardt wrote:
> On 7/17/2020 6:02 PM, Dave Froble wrote:
>
>> 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.

unread,

Jul 18, 2020, 3:25:19 PM7/18/20

to

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

Chris Scheers

unread,

Jul 18, 2020, 3:26:52 PM7/18/20

to

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

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

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

Arne Vajhøj

unread,

Jul 18, 2020, 3:34:06 PM7/18/20

to

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 Dallman

unread,

Jul 18, 2020, 4:28:41 PM7/18/20

to

In article <008b31c3-f353-4c8a...@googlegroups.com>,

fin...@gmail.com (Alice Wyan) wrote:

> 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

Why should that make a difference?

Simon Clubley

unread,

Jul 20, 2020, 8:10:55 AM7/20/20

to

On 2020-07-17, John Reagan <xyzz...@gmail.com> wrote:
>
> 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.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

Simon Clubley

unread,

Jul 20, 2020, 8:33:34 AM7/20/20

to

On 2020-07-17, Terry Kennedy <terry-...@glaver.org> wrote:
> 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.

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

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 Clubley

unread,

Jul 20, 2020, 8:36:07 AM7/20/20

to

On 2020-07-17, Dave Froble <da...@tsoft-inc.com> wrote:
>
> 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.

Bob Eager

unread,

Jul 20, 2020, 10:07:01 AM7/20/20

to

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

Because...

On 7/17/2020 4:05 PM, Terry Kennedy wrote:

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

--
My posts are my copyright and if @diy_forums or Home Owners' Hub
wish to copy them they can pay me £1 a message.
Use the BIG mirror service in the UK: http://www.mirrorservice.org
*lightning surge protection* - a w_tom conductor

Arne Vajhøj

unread,

Jul 20, 2020, 10:18:44 AM7/20/20

to

On 7/17/2020 4:05 PM, Terry Kennedy wrote:

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

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

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

Arne Vajhøj

unread,

Jul 20, 2020, 10:26:41 AM7/20/20

to

On 7/20/2020 8:33 AM, Simon Clubley wrote:
> On 2020-07-17, Terry Kennedy <terry-...@glaver.org> wrote:
>> 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.
>
> 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

Dave Froble

unread,

Jul 20, 2020, 11:12:16 AM7/20/20

to

On 7/20/2020 8:36 AM, Simon Clubley wrote:
> On 2020-07-17, Dave Froble <da...@tsoft-inc.com> wrote:
>>
>> 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.

Terry Kennedy

unread,

Jul 20, 2020, 11:45:13 AM7/20/20

to

On Monday, July 20, 2020 at 10:18:44 AM UTC-4, Arne Vajhøj wrote:
> On 7/17/2020 4:05 PM, Terry Kennedy wrote:
> > 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.
>
> > 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.
>
> 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.

Simon Clubley

unread,

Jul 20, 2020, 1:12:35 PM7/20/20

to

On 2020-07-20, Arne Vajhøj <ar...@vajhoej.dk> wrote:
> On 7/20/2020 8:33 AM, Simon Clubley wrote:
>> On 2020-07-17, Terry Kennedy <terry-...@glaver.org> wrote:
>>> 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.
>>
>> 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.

> 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

Dave Froble

unread,

Jul 20, 2020, 2:50:01 PM7/20/20

to

On 7/17/2020 6:46 PM, Dave Froble wrote:

> On 7/17/2020 8:35 AM, John E. Malmberg wrote:
>
>>
>> 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."
>

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

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

Bill Gunshannon

unread,

Jul 20, 2020, 4:00:18 PM7/20/20

to

On 7/20/20 10:18 AM, Arne Vajhøj wrote:
>
> 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

Craig A. Berry

unread,

Jul 20, 2020, 6:11:11 PM7/20/20

to

On 7/17/20 5:26 PM, Bill Gunshannon wrote:
> On 7/17/20 1:35 PM, John Reagan wrote:
>> On Friday, July 17, 2020 at 12:41:58 PM UTC-4, Phillip Helbig (undress
>> to reply) wrote:
>>> In article <9513122f-5615-4d7c...@googlegroups.com>,
>>> Alice Wyan <fin...@gmail.comwrites:

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

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

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

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

unread,

Jul 20, 2020, 6:50:56 PM7/20/20

to

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

Alexander Schreiber

unread,

Jul 20, 2020, 7:08:10 PM7/20/20

to

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

Dave Froble

unread,

Jul 20, 2020, 9:32:47 PM7/20/20

to

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

unread,

Jul 20, 2020, 11:38:48 PM7/20/20

to

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

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)

Terry Kennedy

unread,

Jul 20, 2020, 11:43:12 PM7/20/20

to

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.

Arne Vajhøj

unread,

Jul 21, 2020, 9:58:12 AM7/21/20

to

On 7/20/2020 4:00 PM, Bill Gunshannon wrote:
> On 7/20/20 10:18 AM, Arne Vajhøj wrote:
>> 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

Stephen Hoffman

unread,

Jul 21, 2020, 3:16:07 PM7/21/20

to

On 2020-07-21 03:38:46 +0000, Bob Wilson said:

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.

--
Pure Personal Opinion | HoffmanLabs LLC

John Reagan

unread,

Jul 21, 2020, 5:07:10 PM7/21/20

to

On Monday, July 20, 2020 at 8:10:55 AM UTC-4, Simon Clubley wrote:
> On 2020-07-17, John Reagan <xyzz...@gmail.com> wrote:
> >
> > 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.

Dave Froble

unread,

Jul 21, 2020, 5:15:26 PM7/21/20

to

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)

unread,

Jul 21, 2020, 5:26:45 PM7/21/20

to

In article <rf7lt9$6ti$1...@dont-email.me>, Dave Froble

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

> 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

unread,

Jul 21, 2020, 6:27:32 PM7/21/20

to

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

bill

Dave Froble

unread,

Jul 21, 2020, 6:36:27 PM7/21/20

to

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

unread,

Jul 21, 2020, 7:05:40 PM7/21/20

to

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

unread,

Jul 21, 2020, 7:51:12 PM7/21/20

to

mor...@world.std.spaamtrap.com (Michael Moroney) writes:

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

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.

David Goodwin

unread,

Jul 21, 2020, 7:54:48 PM7/21/20

to

On Wednesday, July 22, 2020 at 11:05:40 AM UTC+12, Michael Moroney wrote:
> 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.

Robert A. Brooks

unread,

Jul 21, 2020, 9:33:03 PM7/21/20

to

On 7/21/2020 7:51 PM, Michael Moroney wrote:

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

--
-- Rob

Dave Froble

unread,

Jul 21, 2020, 9:39:54 PM7/21/20

to

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?

:-)

Dave Froble

unread,

Jul 21, 2020, 9:43:55 PM7/21/20

to

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

:-(

David Goodwin

unread,

Jul 21, 2020, 10:24:54 PM7/21/20

to

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

unread,

Jul 21, 2020, 10:29:17 PM7/21/20

to

"Robert A. Brooks" <FIRST...@vmssoftware.com> writes:

>On 7/21/2020 7:51 PM, Michael Moroney wrote:

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

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

Noble cause.

Bob Wilson

unread,

Jul 21, 2020, 10:56:21 PM7/21/20

to

> 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

unread,

Jul 21, 2020, 11:12:43 PM7/21/20

to

> 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

unread,

Jul 22, 2020, 12:08:21 AM7/22/20

to

Bob Wilson <bwa...@gmail.com> writes:

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

VAXman-

unread,

Jul 22, 2020, 7:33:20 AM7/22/20

to

In article <rf850d$kg3$1...@dont-email.me>, "Robert A. Brooks" <FIRST...@vmssoftware.com> writes:
>On 7/21/2020 7:51 PM, Michael Moroney wrote:
>

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

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

unread,

Jul 22, 2020, 9:02:37 AM7/22/20

to

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.

Arne Vajhøj

unread,

Jul 22, 2020, 9:28:15 AM7/22/20

to

On 7/22/2020 9:02 AM, Simon Clubley wrote:
> On 2020-07-22, Arne Vajhøj <ar...@vajhoej.dk> wrote:
>> On 7/22/2020 8:34 AM, Simon Clubley wrote:
>>> 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

unread,

Jul 22, 2020, 10:35:43 AM7/22/20

to

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

unread,

Jul 22, 2020, 11:21:54 AM7/22/20

to

On 7/22/2020 10:35 AM, Jan-Erik Söderholm wrote:
> 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

unread,

Jul 22, 2020, 11:52:17 AM7/22/20

to

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

:-)

Robert A. Brooks

unread,

Jul 22, 2020, 12:40:51 PM7/22/20

to

On 7/22/2020 8:34 AM, Simon Clubley wrote:

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

--

-- Rob

Jan-Erik Söderholm

unread,

Jul 22, 2020, 12:42:51 PM7/22/20

to

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

unread,

Jul 22, 2020, 4:07:39 PM7/22/20

to

Hans Bachner wrote:
> Chris Scheers schrieb am 18.07.2020 um 21:26:
>> John H. Reinhardt wrote:
>>> On 7/17/2020 6:02 PM, Dave Froble wrote:
>>>
>>>> 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.

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

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

Hans Bachner

unread,

Jul 22, 2020, 4:31:04 PM7/22/20

to

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

Hans.

Simon Clubley

unread,

Jul 23, 2020, 1:38:44 PM7/23/20

to

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.