[TUHS] Re: UNIX on (not quite bare) System/370

[Clem Cole <clemc@ccc.com>]

[-- Attachment #1: Type: text/plain, Size: 3289 bytes --]

On Tue, Dec 20, 2022 at 4:32 AM segaloco via TUHS <tuhs@tuhs.org> wrote:

> This document also mentions docs for UNIX Real-Time-Reliable on the
> 3B20D.  No doubt a MERT and UNIX/RT descendant.

I'm not so sure it was that direct, actually.  This is the work from IH
that I have mentioned from Tom Bishop et al. - a very cool system IMO.  As
I understand from Tom, the team had the earlier docs and code but started
over for different reasons (primarily the need for SSI support). I'm not
sure how many/if any, of the earlier MERT-specific system functions (see
the docs that Heinz got to us on TUHS) were supported.    As I understand
it, few.  The primary target for this system was to control ESS#5, and I
don't think Tom and the team were considering codes that at already been
released and running in the OC on PDP-11-based MERTs.




> 3B5 section mentions a "Release 5.3" so before the System V moniker.
> Farthest I've seen the minor version.
>
Again -- my point about internal AT&T politics.  The 'System x' stuff was
the marketing / legal team in North Carolina.   System development was in
Summit (USG).

You can see two heads of AT&T in this observation of the code base. On the
one hand, the traditional TelCo market, in which the 'UNIXness' was
important, but on the other hand was Charlie Brown's new directive and
being allowed to be in the 'computer business.'  The whole thing about the
System x stuff was created and pushed from NC as part of the latter.   The
folks concentrating on the former, the traditional teams in IH, Columbus,
etc., already understood their customers (the former OCs, now baby Bells).




> Needless to say the system really grew legs in the 80s even inside the
> Bell.
>
Exactly - which is why all of this is so confusing years
later, particularly to folks that did not live the times.   Today (i.e,
years after the fact), we can see many technical results as time points,
such as releases from different teams.  We know the technologies and the
people that created/implemented them.   But very much lost to time is the
content - which is the politics and economics of why things went in
specific directions.

As I have said so often, as technologists, we have to try to remember: that
simple economics beats sophisticated engineering
Yes, this is sometimes grating for us, as we like to look at things from
the technical side. As Larry likes to point out, the new SunVM was
excellent but was tossed in favor of the inferior SVR4, or as Rob says,
Research went with BSD on the Vax, although they too had what seems in
hindsight to have been superior options.

But I will that an experienced >>guess<< both of those were driven, in the
end, by reasons other than pure technology (Larry has discussed the Sun
situation, for instance).  Only someone like Rob or Ken can say why in the
end, BSD was picked -- but having lived these types of choices in other
places, I'd >>bet just using BSD was because 'pure joy' was 'good enough'
to support the Vaxen (which were tools for them) and they had other things
to worry about - and/or their research efforts were no longer directed at
the VM system, but rather other features such like distributed FS, remote
execution and such.


ᐧ

[-- Attachment #2: Type: text/html, Size: 5507 bytes --]