[Info-vax] Regarding VMS on a VAX. Just curious...

[gérard Calliet]

Le 07/05/2020 à 17:52, Stephen Hoffman a écrit :
> On 2020-05-06 23:20:18 +0000, Robert A. Brooks said:
> 
>> On 5/6/2020 6:34 PM, Bill Gunshannon wrote:
>>
>>> So 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.

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