[Info-vax] VAX VMS going forward

[Stephen Hoffman]

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

> On 2020-07-21 01:32:50 +0000, Dave Froble said:
> 
>> 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).

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