Post by Stephen HoffmanSo then, that brings up another question. Even though they have no
plans to have anything to do with the VAX, does the license they have
from HP specifically preclude their doing a VSI VAX Version of VMS?
This question has no doubt been answered in this forum (probably by me) before.
We have the rights to all the VMS sources, so we could release a VAX version.
It's not going to happen.
Dumping comments from several different threads here.
Dear Stephen,
That's your style. Encyclopedic.
I have nothing against the encyclopaedia, I am French myself and
therefore to some extent heir to the immense progress made possible by
the encyclopaedia of Diderot and D'Alembert. And to the same extent I am
an unrestricted admirer of the quantity and quality of the information
that your encyclopaedic efforts bring.
But it is with good reason that the Encyclopedia has been criticized
insofar as behind the total knowledge there is a set of wills that the
encyclopedic format instils and to which it gives an objective value
without appearing to do so.
The summary given by Robert Brooks seems clearer to me and can be summed
up in two sentences: « we can do it, but we will not do it ». I took the
trouble to reread many threads on the subject, and these two sentences
seem to me to be a sufficient summary. Its clarity lies in the fact that
it distinguishes between what is the domain of the objective and what is
the domain of the will. My criticism of your style is that the volunteer
moves forward hidden behind the immensity of the various objective
descriptions.
What is interesting in Robert's two sentences, and which can be related
to your work, can be summed up in one word: *We*. We can, but we don't
want to.
That's the whole problem. Who is this We. We the encyclopedic holders of
all the possible expectations of the VMS ecosystem? We the only
authorized providers? We who are the only ones able to determine all the
needs and motivations in the VMS ecosystem? We, the generals
disappointed in lost battles from which we alone are authorized to
predict the stakes of new battles?
It seems to me that one of the fundamentals of the so-called liberal
economy that is our sandbox is that it remains dependent on a principle
of play, that is to say, on the idea that we can absolutely not
anticipate everything, and that our choices are based on unknowns
accepted and seen as stakes.
So we can have the most encyclopedic view of a given situation, it will
not give us by deduction what we play when we want something. My
philosophical style, I apologise 😉
What paralyzes the decision here is precisely this naive belief that our
We is totally in tune with the issues at stake. This is partly true for
the most active in the VMS ecosystem right now: the sustainability of
the Alpha and Itanium environments and the panacea of x86 porting (I've
said elsewhere what I think about the obsession with this goal and the
danger it represents). But that's obviously completely wrong as far as
VAX/VMS is concerned. « We're not interested so it's not interesting ».
Except that the players for VAX/VMS are not the same as the players for
Alpha/Itanium/x86/VMS.
The players for VAX/VMS are : HPE (« how to get rid of that »), VSI («
why me? »), all the VAX hobbyist communities, the simh community, all
the commercial suppliers of VAX emulators, all the places where VAX are
still used industrially, the worldwide scientific community (it was once
fueled by Digital Labs, but knowledge in computer history is still very
present around VAX).
In the name of what could We (VSI + comp.os.vms) speak for all these
other We? Because we are the most encyclopedically informed? Because we
are the ones who generate the main income? Isn't this precisely what has
always been a trap for the VMS ecosystem: our peremptory vision of
things, our inability to evaluate the existence of other networks of
reasons and interests?
I have always been a fervent spectator of bootcamps, and my passion for
gurus is boundless, and I believe that the VMS Ecosystem is a place
where guru-ism is somehow preserved.
But I must say that I've always been amazed by the peremptory tone of
many of the presentations. Maybe I'm wrong, but it seems to me, for
example, that we were told a lot of definitive things about Alpha that
ended up being completely overturned. Could have we been less peremptory?
Dear Stephen, it's absolutely commendable to know everything about
everything, and infinitely profitable.
The fact remains that as far as this turning point in the predicted
death of VAX/VMS is concerned (xVMS have seen more, for example in
2013), your encyclopedism give me the opportunity of criticism because I
read it rather as a symptom of a lack of universality.
The question about VAX/VMS licenses, hobbyist or not, takes us
obliquely. The populations concerned, the technical cultures at stake,
the deep relation to the history of computer developments are not the
same as the core that makes VMS live and relive at the moment on Alpha,
Itanium and soon x86. So the answer in terms of decision and will does
not belong to us entirely.
If something can be done for VAX/VMS it will be done through the
combined efforts of the communities involved (hobbyist, simh, real
industrial users), the use of the tools that will be found (cf. Bob’s
proposal), the mobilization of interested commercial entities (AVT ware,
Stromasys,...) (they have an interest in the existence of VAX/VMS
skills, it's an indirect need) (their interests are different from those
of the simh community, obviously), and only in the end by the
implementation at VSI and with the blessing of HPE.
I am aware that in our time this kind of conjunction is very
hypothetical. Respect for ancestors, inter-generational transmission, a
taste for history, foundations for non purely commercial purposes, all
these things lend themselves to a smile. As if we didn't know that the
real heroes are not Ada Lovelace, Von Newman or Alan Turner, but Bill
Gates, Mark Zuckerberg or Elon Musk. Isn't the future we wish for on
Mars?
I’m a little bit ashamed to relaunch such a discution. Your effort for
synthesis had a reverse effect on me. As if you were saying : « nothing
more to say, the subject is closed ». Perhaps it is closed separatly for
VSI, for you, for other suppliers or users, but as a whole it is a lot
more opened, and deserve a lot more consideration. It is for sure
important to differentiate central topics to other topics when we deal
with a complex computer situation, but often what has been considered as
not to be mentionned became a point of leveraging. My opinion has always
been that VMS ecosystem is a lot more than specific periods and topics
investments. It is a technical culture, a way of coping with problems,
and the old guys on VAX/VMS or the strange all-and-good VAX/VMS sites
are part of it, deserve more our consideration, will be our blessing.
So : how can we do VAX/VMS again? Concrete willings demanded.
Post by Stephen Hoffman=
Why no OpenVMS VAX build? OpenVMS VAX was ~60,000 source modules and
the associated compilers and build tools and the rest, and a very large
and complex build environment, separate from that of OpenVMS Alpha and
OpenVMS I64 (and likely also from x86-64), and dependencies on cluster
setup and queues and other details, and the last full system rebuild was
performed ~2001, and that cluster and any follow-on cluster no longer
exist, and I'd wager that the migration has had tools and pieces
disappear. So... not something to knock together quickly. it took me a
couple of weeks to port the OpenVMS Alpha build environment to a test
cluster, and that was when all of the tooling was actively maintained
and directly available. After ~20 years and organizational churn, effort
involved will be higher. And new VAX chips date back ~25 years.
The market for VAX updates is smaller than the market for
OpenVMS—OpenVMS VAX support ended long ago, and there haven't been new
VAX patches for quite some time—and the need for and the market for a
working and performant VSI OpenVMS port on x86-64 is far more important
for the future of OpenVMS than is investing in preserving those folks
still using VAX hardware or VAX emulation.
=
Hobbyist OpenVMS? Hobbyist OpenVMS VAX?
If you're a hobbyist and want to use OpenVMS VAX and with legitimate
licenses, might want to ask the folks at HPE to generate folks a
farewell gift of permanent hobbyist PAKs for OpenVMS VAX.
If you're a hobbyist and want OpenVMS with legitimate licenses, that
path will be x86-64 and whatever hobbyist program VSI bakes. OpenVMS VAX
will not be a good starting point. OpenVMS VAX isn't a good starting
point now.
Handing an inexperienced-with-OpenVMS hobbyist an OpenVMS VAX system is
a Bad Idea, as OpenVMS is different enough and difficult enough to
learn, and ~25 year old networking and compilers and tools makes
learning about OpenVMS that much more difficult. And VAX adds a pile of
old hardware or hardware emulation into the effort a new hobbyist must
contend with.
For those hobbyists that knew or know OpenVMS and for those dedicated
computing retronauts, VAX and OpenVMS VAX, sure, have at.
I suspect one of the major reasons why OpenVMS VAX hobbyist is popular
right now is a working (free) hardware emulator. If there were a
similarly robust and free Alpha or Itanium emulator available for the
hardware-lacking folks, we'd likely be in an entirely different
discussion. And yes, there are and will be those folks that want VAX for
VAX because VAX.
=
Cross-builds, builds, translations...
VAX-11/VMS was cross-built using the integrated PDP-11 hardware support
in VAX and using hunks of RSX-11M. VAX/VMS itself was dependent on
PDP-11 hardware support for the first three major versions. VAX/VMS only
went fully VAX native at V4.0. SYE was one of the last pieces to migrate
native, though there were a few others.
OpenVMS Alpha was initially cross-built from VAX and that initially
targeting Alpha hardware emulators (the so-called ADU Alpha Development
Units), and then actual working Alpha hardware. All production Alpha
releases were native-built. There were a few translated components that
lingered, and TECO was among those.
OpenVMS I64 followed the same general path as Alpha, though did not fork
the build environments, and was initially cross-built from Alpha, and
all production releases were native built. Again, with some few
facilities using binary-translation tools.
AFAIK, no pieces of Alpha or Itanium were cross-built, once the native
build tools were available. Though there were a few hunks that were
binary-translated and a few that were re-coded, as the available tools
could not contend with older app designs or app assumptions or required
app tooling.
The OpenVMS x86-64 lowercase-a alpha release is by all accounts
cross-built from Itanium, and the production releases will reportedly be
native built and probably with some selected re-coded or using binary
translation tooling if and as that becomes available.
=
The OpenVMS Alpha port targeted bug-for-bug compatibility with OpenVMS
VAX, and deliberately did not fix a whole bunch of stuff that was broken
in OpenVMS VAX. And is still broken in OpenVMS Alpha and OpenVMS I64.
Probably going to be broken on OpenVMS x86-64, too, but that's not
available for inspection. The port did fix a whole bunch of
build-related issues, though the build-related tooling for the two
environments was made more consistent over time. The issue that arose
here was reworking and back-porting 64-bit code back to a 32-bit
environment. 64-bit integers were a common problem for C code, and the
choice was to use an array for 64-bit or larger values, or to fork the
code, or to use conditional builds and which made the source code that
much more involved.
The OpenVMS Alpha 64-bit transition could not be compatible with OpenVMS
VAX, and definitely diverged. That happened in the virtual addressing,
in the compilers and linker, and elsewhere. The design choice at the
time was to go native, flat 64-bit and which was viewed as a better
long-term solution, or to go with a more complex and hybrid 32- and
64-bit design that was going to be a problem longer-term. The choice to
use the 32- and 64-bit hybrid design—a quite interesting design, and one
that did succeed with its goals—was intended to preserve those sites
that had already had 32-bit apps and shareable images and dependencies,
and were not going to upgrade those, and the hybrid design allowed
retrofitting 64-bit addressing into those existing environments. Without
requiring the prerequisite apps to be upgraded to 64-bit. Which was a
very successful approach for piecemeal 64-bit projects. But the
32-/64-bit hybrid design stinks large for new work, and has made
existing apps adopting 64-bit addressing much more complex, and made
OpenVMS itself that much more complex with the mumble64 APIs and ABIs,
with forked code, and with the conditional 32-/64-bit code across the
APIs and ABIs. And not starting anew with 64-bit lost an opportunity to
fix latent 32-bit issues for end-users and developers.
=
There was and is no right choice here, just various trade-offs and wrong
choices.