[Info-vax] VAX VMS going forward

[Terry Kennedy]

On Monday, July 20, 2020 at 9:32:47 PM UTC-4, Dave Froble wrote:
> On 7/20/2020 6:50 PM, Bill Gunshannon wrote:
> > On 7/20/20 6:11 PM, Craig A. Berry wrote:
> >>
> >> 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-b9aa-f97699920cfdo at googlegroups.com>,
> >>>>> Alice Wyan <finitud at 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.
> >
> > 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
> >
> 
> 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

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.