[Info-vax] VAX VMS going forward

[Dave Froble]

On 7/21/2020 3:16 PM, Stephen Hoffman wrote:
> 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.
>
>

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

:-)

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