[TUHS] VAX System V

[Clem Cole via TUHS]

Note that I was the project leader for the last few Ultrix releases, as
well as the architect of TruCluster FS and part of Tru64. [In fact, I had lunch
yesterday with our old VP from those days].

First, be careful.  The System V Vax systems were different from either
Ultrix or Tru64.  It was done by a DEC team in NJ with a lot of help from
the Boston Office of Locus Computing Corp [where I was also the sr
technologist for a few years before my later DEC time].  IIRC, the VAX
System V 3.2.1 fully supported VM (early VAX releases did not, but by the
V3 timeframe, the basic V3 kernel assumed VM hardware, and there would have
been no reason not to use it on the Vax).

That said, compared to any BSD release or Ultrix, by then *the whole system
was fairly vanilla*, just as it was with SVR3 for the 3B20 (also vanilla).
 ISTR that, unlike Ultrix, even the development tool suite was AT&T's PCC3
at that point. So C and Fortran would not have been much to write about.
 Frankly, DEC's VAX11/C, VAX Fortran (and Pascal) were all much better
compilers,
but after the surgery it took to get them to work for Ultrix, I don't think
DEC was interested in moving them again (I'm having lunch tomorrow with a
number of the Technical Languages folks, and if any of the DEC  tool chain
was moved to System V they would know).

I do remember that for VAX System V, there were some contractual extras,
such as X11.  But the networking stack was stream-based, not socket-based.
 I don't remember whether either IP/TCP or NFS was part of the contract,
but they had been; I suspect they would have been Lachman's. System V was
just too different from Ultrix (which was mostly BSD-like) to make sense.

The DEC System V for Vax product was a pure System V code base with only
extensions required by ATT.  I'm not even sure anyone but AT&T or the RBOCs
could order it. It was created to offload ATT’s Summit team (USG) after
they wanted to concentrate on their own ISA, while still having many Vaxen
running throughout the Bell System.  This was really similar to the UNIX
team that started in MK as part of the DEC Telephone Industries group (TIG)
to support the PDP-11s and Vaxes that DEC's largest customer was buying.
 The team in MK was moved to the same building (on a different floor) as
the VMS when Ultrix became a product.  Note that LCC was the primary Ultrix
support team towards the end, when the Unix folks started to concentrate on
Alpha and became the Tru64 team, but DEC had a large installed base of Vaxen
and MIPS systems (for instance, LCC did the MIP 4400 support and all the
last Vax and MIPS releases).   Certainly, in the TIG timeframe when they
were in MK, the UNIX folks were a "redheaded stepchild," compared to VMS
(or TOPS-20 at the time).

So you are correct that *before **Tru64*, TIG and the original Ultrix teams
were often pushed aside by VMS.   But that really changed when DEC started to
see the sales numbers and the complete industry switch off of proprietary
to what was then called the "open systems" marketplace.  Once UNIX was
driving so much revenue, the UNIX folks (Ultrix) were able to drive the
business.  In fact, if you know the history of Windows/NT, it was
originally called "Mica" and was developed by Cutler and team in Seattle.
The whole idea was to switch to a single microkernel and then have the
personalities of VMS or Ultrix layered on top, while allowing greater
commonality across the layered products.   I'll not comment much more than
to say, as VMS was starting to be marginalized, Cutler was less than
pleased.  Eventually, he went to Microsoft†.

By that time, the pecking order was Ultrix (later Tru64), VMS, and then the
Summit folks.    In fact, Alpha ran Ultrix before it ran anything else, and
all the debugging was done there or later when OSF/1 was stable.  VMS and
NT4 were implemented on Alpha only after the core Unix ecosystems had
stabilized [it probably helped that many of the old 36-bit folks had joined
the Unix team, and there was definite animosity toward how VAX/VMS had shut
out the 36-bit products].  There was never a reason to run System V on
it, as AT&T and the RBOC had moved on to the different members of the 3B
family or to Intel platforms.  I'm not sure when the DEC Summit NY office
closed, but at some point DEC tossed a bunch of the residual support
contracts for AT&/RBOC to folks like Lcc.

Clem



†  I'll add one more historical note, as a risk of diverting this thread a
little, NT at Microsoft was originally NT OS/2.  Mica/ney NT was designed
as a microkernel, which is why Culture could quickly switch to a Windows
personality when Microsoft and IBM divorced.




On Wed, Jun 10, 2026 at 2:43 AM Kevin Bowling via TUHS <tuhs at tuhs.org>
wrote:

> I got a manual set for Digital VAX System V 3.2.1.  It appears to be a
> descendent of AT&T's VAX port, but it was thoroughly extended with
> large system hardware support (including CI bus) and even sundries
> like X11R4.  Compared to i.e. 3B2 System V which IMHO is pretty bare
> bones and even a little half baked.  The manuals are actually pretty
> great.
>
> I'm not overly familiar with DEC but perusing history it seemed to be
> that Ultrix was always playing second fiddle to VMS.  VAX System V
> seems like a "more serious" UNIX, it targets the large machines:  VAX
> 11/780, 6000, 8000, 9000.  Only in the 3.2.1 release did a MVII pop
> in.
>
> I don't think I've ever seen anything on this in the wild, the main
> customer appeared to be AT&T itself and the RBOCs.  Information online
> is scare.
>
> Regards,
> Kevin
>