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

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

[Phil Budne]

The October 1984 BSTJ article by Felton, Miller and Milner
https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf

Describes an AT&T port of UNIX to System/370 using TSS/370
underpinnings as the "Resident System Supervisor" and used as the 5ESS
switching system development environment.

I also found mention at http://www.columbia.edu/~rh120/ch106.x09
chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96:

      Ian Johnstone, who had been the tutor at University of New
      South Wales working with Professor John Lions, was one of the
      researchers invited to Bell Labs. He managed the completion at
      AT&T Bell Labs of the port of Unix to the IBM 370 computer. See
      "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX
      Review, October, 1984, p. 26. Johnstone also led the group that did
      the port to the AT&T 2B20A multiprocessor system.

I found
https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf
"BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers rationale.

Also:

	"IBM's own involvement in Unix can be dated to 1979, when it
	assisted Bell Labs in doing its own Unix port to the 370 (to
	be used as a build host for the 5ESS switch's software). In
	the process, IBM made modifications to the TSS/370 hypervisor
	to better support Unix.[12]"
at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0

Is there any other surviving documentation about the system?
Any recall of what branch of AT&T UNIX it was based on?

Thanks!
Phil

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

[segaloco via TUHS]

All I can comment is there are a number of #ifdef u370 sections added to System V.  Happened somewhere between 3.0 and 5.0, likely UNIX/TS.  This is my understanding of Bell-adjacent platform work:

PDP-7          - Research, 1969
PDP-11         - Research, 1970
Interdata 8/32 - Research, 1977
VAX            - Research, 1979 (or did USG do 32V, it's sitting in my USG folder...)
3B20           - UNIX/TS 4.x, 1981
System/370     - UNIX/TS?, 198x
3B5            - Release 5.0, 1982
M68000         - System V, 1983
Z8000          - System V, 1983

And sources are obvious for PDP-7, PDP-11, Interdata, and VAX. 3B20 I based on the 4.1 manual, unsure if it was integrated any earlier. M68000 and Z8000 are based on entries in the AT&T documentation catalogue from 1984, among other things, they mention System V documentation for M680000 and Z8000.  The machid man page in System V lists pdp11, u3b, u3b5, and vax.  The 370 references I'm aware of are all in code.  I can try and pinpoint that if anyone wants me to look, a grep for u370 should suffice though.  In any case, machid in my 5.0 manual does not list M68000, Z8000, nor System/370.

Also ran upstairs and checked some of my other manuals, I find no reference of machid in the SVR2 era manual I have, but it isn't a formal release-version manual, it's "The UNIX System User's Manual" with the red AT&T cover that was the motif at the time.  It seems to be a much more general manual, meant to encompass multiple versions and just the basics.  It's actually pretty interesting in typography and layout, I'll see if that thing has been scanned yet, and if not, will add it to my list.

Checking the actual System V branded manual, it removes the 3b5 reference, perhaps 3b5 was still pretty internal at the time.  The 3b5 reference *is* in the Bell Labs Release 5.0 manual variant, so appears to have just been scrubbed from commercial release material.

Fast forwarding to SVR4, that adds u3b2, u3b15, and u370, so System/370 UNIX was formalized and promoted somewhere between SVR1 and SVR4, pointing more strongly to it being the work of USG and the UNIX/TS line.  That's my initial analysis, I feel like I saw mention of 370 in some sort of papers from around this timeframe, so will respond if I find anything else.  Unfortunately I have a gaping SVR2/SVR3 hole in my library that I don't intend to fill until I work my scan backlog down.

- Matt G.

------- Original Message -------
On Monday, December 19th, 2022 at 9:38 AM, Phil Budne <phil@ultimate.com> wrote:


> The October 1984 BSTJ article by Felton, Miller and Milner
> https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
> 
> Describes an AT&T port of UNIX to System/370 using TSS/370
> underpinnings as the "Resident System Supervisor" and used as the 5ESS
> switching system development environment.
> 
> I also found mention at http://www.columbia.edu/~rh120/ch106.x09
> chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96:
> 
> Ian Johnstone, who had been the tutor at University of New
> South Wales working with Professor John Lions, was one of the
> researchers invited to Bell Labs. He managed the completion at
> AT&T Bell Labs of the port of Unix to the IBM 370 computer. See
> "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX
> Review, October, 1984, p. 26. Johnstone also led the group that did
> the port to the AT&T 2B20A multiprocessor system.
> 
> I found
> https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf
> "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers rationale.
> 
> Also:
> 
> "IBM's own involvement in Unix can be dated to 1979, when it
> assisted Bell Labs in doing its own Unix port to the 370 (to
> be used as a build host for the 5ESS switch's software). In
> the process, IBM made modifications to the TSS/370 hypervisor
> to better support Unix.[12]"
> at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0
> 
> Is there any other surviving documentation about the system?
> Any recall of what branch of AT&T UNIX it was based on?
> 
> Thanks!
> Phil

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

[Clem Cole]

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

On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS <tuhs@tuhs.org> wrote:

> All I can comment is there are a number of #ifdef u370 sections added to
> System V.  Happened somewhere between 3.0 and 5.0, likely UNIX/TS.  This is
> my understanding of Bell-adjacent platform work:
>
> PDP-7          - Research, 1969
> PDP-11         - Research, 1970
> Interdata 8/32 - Research, 1977
> VAX            - Research, 1979 (or did USG do 32V, it's sitting in my USG
> folder...)
> 3B20           - UNIX/TS 4.x, 1981
> System/370     - UNIX/TS?, 198x
> 3B5            - Release 5.0, 1982
> M68000         - System V, 1983
> Z8000          - System V, 1983
>
>
Sadly, do I wish it was this linear as you present ;-)    Simply - it was
not.

Just like the folks outside of the Bell System, inside, there were several
forks, many of which have been discussed here.

Research was its own bloodline.  Ken/Dennis et al..   This, of course, was
what seeded much of the external work at the Universities with the BSD
bloodline as a direct result. There was a good bit of porting work done
there, such as the work on the Interdata,  IBM S/360,  and Honeywell, but
most of that work tended to leave the labs in an indirect form.

PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al...  as a
fork of Research Sixth Edition.  After many twists and turns, that
bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve
Johnson - a.k.a. yaccman - was a manager in Summit and has offered some
enlightenment on this list over the years).  As we have often discussed
here, the TS line is hugely impure.  There is a great question of what was
TS and what was not.  What was the name and what was actual technology?
It's clear it started based on AT&T politics of the mid-late 70s, but as
things changed at AT&T and their own internal Unix wars - names and
technologies shave been blurred and some of the details were lost to time.
 We know that the PWB thread  (and >>name<< ) would >>eventually<< become
the many flavors of Sys V and it was the 'official' line that AT&T started
to market -- at first to the Operating Companies and later more widespread
commercially.  What was PWB and what was TS is not completely clear? (I
think Werner may have done so of the best sleuthing here and has reported
his learnings in the past).

Part of the issues we have as historians was because threads and those
twists and turns started before the breakup and were controlled by rules of
the 1956 consent decree (TS and PWB itself are examples) and other things
happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at
being in the computer business.  Pre breakup, the AT&T >>commercial<< work
was targeted for the Operating Companys. Each group often did different
things to deal with specific projects that were being targeted to solve
problems that the OCs had.

As was pointed out before, the switching folks in Indian Hill not only
needed to build things like SW for the ESS#5 (the 370/TSS-based stuff
mentioned yesterday helped to support that project) but they were also
working on a very slick single system image Unix system [Tom Bishop at
friends] that ran on the 3B duplex and some other HW - the /400 IIRC]
(FWIW: Tom used to be findable - I've tried to get him on this list a few
times).  But you will see some #ifdefs in various codes that ended back up
in Summit that really are from that work.   That said, if I understand
things that have been suggested here, officially the Duplex system used an
OS that Indian Hill created but was >>seeded<< from Summit, but not the
Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc
might have].

Holmdel ( Reisner et al.) had several projects.  The best we3 can tell,
is that bloodline seems to have died off due to some internal AT&T politics
and reorgs, although a  number of things from it seem to have shown up in
other bloodlines and different people brought some of the ideas.  For
instance, while it's not directly there, SVR3's memory system >>seems<< to
have had some Reisner's influence.   Again we don't have direct evidence
other than different people's recollections and some comments people here
and elsewhere have found in different sources.

Columbus ( Dale's team ) did a great deal of work in several areas.  Some
of it has been recovered, but not all.  Mary Ann, is a one-time member of
that team and often comments and fills in some of the history here.  FWIW:
The PWB 3.0, a.k.a. System III release, got a bunch of the technology from
CBUNIX (again discussed at length here over the years) - shared mem,
semaphore, ipc, etc.

These are just a few and I apologize to anyone that was not mentioned.  I
offered some highlights to make my point.

If you are newer to the list, I respectfully suggest that instead of
restarting some of this discussion, please go back into the old Mail
archives and you will see a great deal of detail.

The most important point I will leave you with is that the different UNIX
flavors influenced each other - inside and outside the Bell System.  As
Larry points out, politics often had a more substantial influence on what
'won' than the 'goodness' of the technology itself in many cases.  But the
path from the root to any of the leaves includes a great deal of
cross-fertilization. It seems to me to be a bit disingenuous to offer a
linear statement from one of the bloodlines and infer that was how it all
worked, just because some #ifdefs have been found in a few places in some
of the different pieces of code, be kernel portions or user space.
ᐧ
ᐧ

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

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

[Rob Pike]

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

Quite a bit of this feels not exactly wrong, but not quite right. (And his
name is John Reiser, not Reisner.) Steve Johnson didn't go to work in
development until the mid 1980s, for example, long after these bloodlines
as you call them were laid down.

Do we know that PWB became USG? That doesn't feel right to me, although it
might well be true, I wasn't there. I think of it as mostly staying in
Whippany, not going to Summit. Also your prose would imply USG never got to
V7 level, which is certainly not true. Columbus's major contribution, as we
saw it from Research, was the world's second most complex init. All these
variants lobbied to have Research adopt things, as such approval was seen
as a badge of honor. Honestly, though, it was all pretty toxic.

Reiser and London's Unix, which I greatly admired, died on the vine for a
variety of political reasons, as well as because it had slightly different
semantics in some important cases, and because of a broad antipathy to
virtual memory across the company due to various people having used VM on
inadequate hardware, and of course then there was Multics. Sandy Fraser was
very nervous about Research adopting the BSD kernel because of his
experience with Atlas. But let it be said: Reiser's VM system was seriously
impressive, cleanly integrated, structurally central, and wonderfully fast.
And Sandy relented but the general warmth of 1127 towards Berkeley led to
Research adopting Berkeley Unix as its VAX VM platform, despite some,
including myself, feeling that was the inferior choice.

-rob


On Tue, Dec 20, 2022 at 8:03 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>
>> All I can comment is there are a number of #ifdef u370 sections added to
>> System V.  Happened somewhere between 3.0 and 5.0, likely UNIX/TS.  This is
>> my understanding of Bell-adjacent platform work:
>>
>> PDP-7          - Research, 1969
>> PDP-11         - Research, 1970
>> Interdata 8/32 - Research, 1977
>> VAX            - Research, 1979 (or did USG do 32V, it's sitting in my
>> USG folder...)
>> 3B20           - UNIX/TS 4.x, 1981
>> System/370     - UNIX/TS?, 198x
>> 3B5            - Release 5.0, 1982
>> M68000         - System V, 1983
>> Z8000          - System V, 1983
>>
>>
> Sadly, do I wish it was this linear as you present ;-)    Simply - it was
> not.
>
> Just like the folks outside of the Bell System, inside, there were several
> forks, many of which have been discussed here.
>
> Research was its own bloodline.  Ken/Dennis et al..   This, of course, was
> what seeded much of the external work at the Universities with the BSD
> bloodline as a direct result. There was a good bit of porting work done
> there, such as the work on the Interdata,  IBM S/360,  and Honeywell, but
> most of that work tended to leave the labs in an indirect form.
>
> PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al...  as a
> fork of Research Sixth Edition.  After many twists and turns, that
> bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve
> Johnson - a.k.a. yaccman - was a manager in Summit and has offered some
> enlightenment on this list over the years).  As we have often discussed
> here, the TS line is hugely impure.  There is a great question of what was
> TS and what was not.  What was the name and what was actual technology?
> It's clear it started based on AT&T politics of the mid-late 70s, but as
> things changed at AT&T and their own internal Unix wars - names and
> technologies shave been blurred and some of the details were lost to time.
>  We know that the PWB thread  (and >>name<< ) would >>eventually<< become
> the many flavors of Sys V and it was the 'official' line that AT&T started
> to market -- at first to the Operating Companies and later more widespread
> commercially.  What was PWB and what was TS is not completely clear? (I
> think Werner may have done so of the best sleuthing here and has reported
> his learnings in the past).
>
> Part of the issues we have as historians was because threads and those
> twists and turns started before the breakup and were controlled by rules of
> the 1956 consent decree (TS and PWB itself are examples) and other things
> happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at
> being in the computer business.  Pre breakup, the AT&T >>commercial<< work
> was targeted for the Operating Companys. Each group often did different
> things to deal with specific projects that were being targeted to solve
> problems that the OCs had.
>
> As was pointed out before, the switching folks in Indian Hill not only
> needed to build things like SW for the ESS#5 (the 370/TSS-based stuff
> mentioned yesterday helped to support that project) but they were also
> working on a very slick single system image Unix system [Tom Bishop at
> friends] that ran on the 3B duplex and some other HW - the /400 IIRC]
> (FWIW: Tom used to be findable - I've tried to get him on this list a few
> times).  But you will see some #ifdefs in various codes that ended back up
> in Summit that really are from that work.   That said, if I understand
> things that have been suggested here, officially the Duplex system used an
> OS that Indian Hill created but was >>seeded<< from Summit, but not the
> Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc
> might have].
>
> Holmdel ( Reisner et al.) had several projects.  The best we3 can tell,
> is that bloodline seems to have died off due to some internal AT&T politics
> and reorgs, although a  number of things from it seem to have shown up in
> other bloodlines and different people brought some of the ideas.  For
> instance, while it's not directly there, SVR3's memory system >>seems<< to
> have had some Reisner's influence.   Again we don't have direct evidence
> other than different people's recollections and some comments people here
> and elsewhere have found in different sources.
>
> Columbus ( Dale's team ) did a great deal of work in several areas.  Some
> of it has been recovered, but not all.  Mary Ann, is a one-time member of
> that team and often comments and fills in some of the history here.  FWIW:
> The PWB 3.0, a.k.a. System III release, got a bunch of the technology from
> CBUNIX (again discussed at length here over the years) - shared mem,
> semaphore, ipc, etc.
>
> These are just a few and I apologize to anyone that was not mentioned.  I
> offered some highlights to make my point.
>
> If you are newer to the list, I respectfully suggest that instead of
> restarting some of this discussion, please go back into the old Mail
> archives and you will see a great deal of detail.
>
> The most important point I will leave you with is that the different UNIX
> flavors influenced each other - inside and outside the Bell System.  As
> Larry points out, politics often had a more substantial influence on what
> 'won' than the 'goodness' of the technology itself in many cases.  But the
> path from the root to any of the leaves includes a great deal of
> cross-fertilization. It seems to me to be a bit disingenuous to offer a
> linear statement from one of the bloodlines and infer that was how it all
> worked, just because some #ifdefs have been found in a few places in some
> of the different pieces of code, be kernel portions or user space.
> ᐧ
> ᐧ
>

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

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

[segaloco via TUHS]

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

If it helps any, the init discrepancies are one of the hints at part of the System III/3.0 lineage. System III has an init much closer in flavor to CB init than the research init (inittab, runlevels).

There are notable differences too, the inittab is in a slightly different format and the runlevels are simply 1-9, no s/S alias for single user mode afaik. 4.1 appears to be the first release to have split a_man and u_man, and I only managed to track down a user manual, so can't compare the init and getty pages, but the inittab entry matches System III, meaning that CB init as we know it didn't make it in until 5.0. In any case, a diff on the III and V versions is pretty stark, leading me to believe if CB init was inspired by this, it was in design only, but possibly a fresh codebase? So hard to tell.

Where this leaves a quandary is where did this init in System III come from? Not a System/370 matter but if anyone knows I'd love to hear you out.

Another matter I've been keeping tabs on in my recent study is the presence of SCCS tags on things. Most System V code has SCCS tags, but only select bits of System III seem to have them. Where they do exist, often times they're either carried through to the System V file verbatim or​ there's some monkeying with the numbers I can't quite explain but I have some hunches. In any case, many of the files unmodified between III and V are listed as SCCS version 1.1 in V. I'm not sure there what the significance of the version numbers was, and in analyzing several versions, i haven't been able to identify a singular pattern. One pattern I did notice sporadically was when comparing SVR1 Release 1 (PDP-11) and SVR1 Release 2 (M68K), all of these SCCS identifiers I checked roll from whatever 1.x they were in the former to 2.1 in the latter, presumably the major number being the System V release and minor being revisions since that was tagged? All speculation though.

In any case, Clem is totally right that nothing is that linear, I was just pulling some references from some documents I have on hand to fill in some of the available context. At the root of it all though there is u370 in the PDP-11 codebase for SVR0/1 (never know which to apply...). So at least by 1982 there was definitely System/370 stuff floating around far enough up the chain to be integrated. Where those actual lines of code came from, can't entirely say, although I have a document I'm scanning tonight that miiiight shed some more light. Appendix I of the System Release Description document for System V is a 62 page list of all the modification requests presumably between 3.0 and 5.0. It's a table with header "NR AREA SUMMARY MR" where NR is just an increasing number, AREA is a rough idea of where it's at (some have program names, some have text like "3.0 manual", SUMMARY is basically a commit message, and then MR is two letters (location/team?), two numbers (year?), a dash, then 5 numbers (issue number?). There are plenty of u370 references throughout, for instance

775 graphics union adrbits in file xytekl.c must be inverted for unix 370 bl81-21610
786 grep an #ifdef should be around u370 code bl81-28302

There are others, just did a quick visual scan for some examples. I've got the entire rest of the document scanned already, just need to get Appendix I and upload it. I think this'll be very informative of what was going on in that timeframe. Unfortunately the order is not chronological as far as I can tell, so it'll take OCR'ing this and then sorting on the MR column to get something like that out of it. I also don't know if the MR number is representative of when something was fixed or reported. Given MR is Modification Request, my assumption is any chronological data is predicated on the report date, not fix date.

Anywho I'll hopefully have that and the other PDFs from that volume somewhere folks can get to them by this evening. Decided to ramp up getting this thing scanned since it'll also contribute to what is pretty much turning into a UNIX 4.x restoration for me. Anywho, hopefully this thing turns up some timelines. More to come!

- Matt G.

------- Original Message -------
On Monday, December 19th, 2022 at 1:19 PM, Rob Pike <robpike@gmail.com> wrote:

> Quite a bit of this feels not exactly wrong, but not quite right. (And his name is John Reiser, not Reisner.) Steve Johnson didn't go to work in development until the mid 1980s, for example, long after these bloodlines as you call them were laid down.
>
> Do we know that PWB became USG? That doesn't feel right to me, although it might well be true, I wasn't there. I think of it as mostly staying in Whippany, not going to Summit. Also your prose would imply USG never got to V7 level, which is certainly not true. Columbus's major contribution, as we saw it from Research, was the world's second most complex init. All these variants lobbied to have Research adopt things, as such approval was seen as a badge of honor. Honestly, though, it was all pretty toxic.
>
> Reiser and London's Unix, which I greatly admired, died on the vine for a variety of political reasons, as well as because it had slightly different semantics in some important cases, and because of a broad antipathy to virtual memory across the company due to various people having used VM on inadequate hardware, and of course then there was Multics. Sandy Fraser was very nervous about Research adopting the BSD kernel because of his experience with Atlas. But let it be said: Reiser's VM system was seriously impressive, cleanly integrated, structurally central, and wonderfully fast. And Sandy relented but the general warmth of 1127 towards Berkeley led to Research adopting Berkeley Unix as its VAX VM platform, despite some, including myself, feeling that was the inferior choice.
>
> -rob
>
> On Tue, Dec 20, 2022 at 8:03 AM Clem Cole <clemc@ccc.com> wrote:
>
>> On Mon, Dec 19, 2022 at 1:54 PM segaloco via TUHS <tuhs@tuhs.org> wrote:
>>
>>> All I can comment is there are a number of #ifdef u370 sections added to System V. Happened somewhere between 3.0 and 5.0, likely UNIX/TS. This is my understanding of Bell-adjacent platform work:
>>>
>>> PDP-7 - Research, 1969
>>> PDP-11 - Research, 1970
>>> Interdata 8/32 - Research, 1977
>>> VAX - Research, 1979 (or did USG do 32V, it's sitting in my USG folder...)
>>> 3B20 - UNIX/TS 4.x, 1981
>>> System/370 - UNIX/TS?, 198x
>>> 3B5 - Release 5.0, 1982
>>> M68000 - System V, 1983
>>> Z8000 - System V, 1983
>>
>> Sadly, do I wish it was this linear as you present ;-) Simply - it was not.
>>
>> Just like the folks outside of the Bell System, inside, there were several forks, many of which have been discussed here.
>>
>> Research was its own bloodline. Ken/Dennis et al.. This, of course, was what seeded much of the external work at the Universities with the BSD bloodline as a direct result. There was a good bit of porting work done there, such as the work on the Interdata, IBM S/360, and Honeywell, but most of that work tended to leave the labs in an indirect form.
>>
>> PWB 1.0/2.0 started a different thread - Glaser, Mashey, et al... as a fork of Research Sixth Edition. After many twists and turns, that bloodline would become the Unix Support Group (a.k.a. USG) in Summit (Steve Johnson - a.k.a. yaccman - was a manager in Summit and has offered some enlightenment on this list over the years). As we have often discussed here, the TS line is hugely impure. There is a great question of what was TS and what was not. What was the name and what was actual technology? It's clear it started based on AT&T politics of the mid-late 70s, but as things changed at AT&T and their own internal Unix wars - names and technologies shave been blurred and some of the details were lost to time. We know that the PWB thread (and >>name<< ) would >>eventually<< become the many flavors of Sys V and it was the 'official' line that AT&T started to market -- at first to the Operating Companies and later more widespread commercially. What was PWB and what was TS is not completely clear? (I think Werner may have done so of the best sleuthing here and has reported his learnings in the past).
>>
>> Part of the issues we have as historians was because threads and those twists and turns started before the breakup and were controlled by rules of the 1956 consent decree (TS and PWB itself are examples) and other things happened afterward as Charlie Brown (AT&T CEO) wanted to make a run at being in the computer business. Pre breakup, the AT&T >>commercial<< work was targeted for the Operating Companys. Each group often did different things to deal with specific projects that were being targeted to solve problems that the OCs had.
>>
>> As was pointed out before, the switching folks in Indian Hill not only needed to build things like SW for the ESS#5 (the 370/TSS-based stuff mentioned yesterday helped to support that project) but they were also working on a very slick single system image Unix system [Tom Bishop at friends] that ran on the 3B duplex and some other HW - the /400 IIRC] (FWIW: Tom used to be findable - I've tried to get him on this list a few times). But you will see some #ifdefs in various codes that ended back up in Summit that really are from that work. That said, if I understand things that have been suggested here, officially the Duplex system used an OS that Indian Hill created but was >>seeded<< from Summit, but not the Summit released directly [i.e., IH acted the same way as DEC, Sun, IBM, etc might have].
>>
>> Holmdel ( Reisner et al.) had several projects. The best we3 can tell, is that bloodline seems to have died off due to some internal AT&T politics and reorgs, although a number of things from it seem to have shown up in other bloodlines and different people brought some of the ideas. For instance, while it's not directly there, SVR3's memory system >>seems<< to have had some Reisner's influence. Again we don't have direct evidence other than different people's recollections and some comments people here and elsewhere have found in different sources.
>>
>> Columbus ( Dale's team ) did a great deal of work in several areas. Some of it has been recovered, but not all. Mary Ann, is a one-time member of that team and often comments and fills in some of the history here. FWIW: The PWB 3.0, a.k.a. System III release, got a bunch of the technology from CBUNIX (again discussed at length here over the years) - shared mem, semaphore, ipc, etc.
>>
>> These are just a few and I apologize to anyone that was not mentioned. I offered some highlights to make my point.
>>
>> If you are newer to the list, I respectfully suggest that instead of restarting some of this discussion, please go back into the old Mail archives and you will see a great deal of detail.
>>
>> The most important point I will leave you with is that the different UNIX flavors influenced each other - inside and outside the Bell System. As Larry points out, politics often had a more substantial influence on what 'won' than the 'goodness' of the technology itself in many cases. But the path from the root to any of the leaves includes a great deal of cross-fertilization. It seems to me to be a bit disingenuous to offer a linear statement from one of the bloodlines and infer that was how it all worked, just because some #ifdefs have been found in a few places in some of the different pieces of code, be kernel portions or user space.
>> ᐧ
>> ᐧ

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

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

[Brad Spencer]

segaloco via TUHS <tuhs@tuhs.org> writes:

[snip]

> Another matter I've been keeping tabs on in my recent study is the presence of SCCS tags on things. Most System V code has SCCS tags, but only select bits of System III seem to have them. Where they do exist, often times they're either carried through to the System V file verbatim or​ there's some monkeying with the numbers I can't quite explain but I have some hunches. In any case, many of the files unmodified between III and V are listed as SCCS version 1.1 in V. I'm not sure there what the significance of the version numbers was, and in analyzing several versions, i haven't been able to identify a singular pattern. One pattern I did notice sporadically was when comparing SVR1 Release 1 (PDP-11) and SVR1 Release 2 (M68K), all of these SCCS identifiers I checked roll from whatever 1.x they were in the former to 2.1 in the latter, presumably the major number being the System V release and minor being revisions since that was tagged? All speculation though.

[snip]

Someone else will have to indicate if raw SCCS was used during the time
frame for the code you are looking at or if there was some management
system built on SCCS that was actually used.

What I mean by this is that there was a source code control management
system used at AT&T and later Lucent called Sublime (it was more or less
mandated at CB at least for the software groups I know of and I am
pretty sure I remember it in other locations too).  Sublime was used in
the '90s onward and likely quite a bit before that time.  This system
was a layer on top of SCCS, which wasn't allowed to be used directly for
source code control.  It was true that SCCS tags ended up in your code
(usually), but you could not directly use the tag information in any
meaningful manor.  Sublime used the tag information in it own way that
was opaque to the software developers.





-- 
Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

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

[Adam Thornton]

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

If anyone wants to play with UTS--the version I'm running has sources that
indicate it's pretty much a v7--you can connect to it at
https://mvsevm.fsf.net, resize your window so the terminal is 80x25, pick
option 11 (VM/370), hit enter, and then after the logo goes away type "DIAL
UTS".

The passwords are findable via a web search for something like "uts vm/370
password" in that I have not changed them from the defaults.  If you manage
to break out of UTS into VM, and from there into Hercules, and from that to
the physical host, and then from there compromise my network, I'd like to
know how you did it.  If on the other hand you're going to mine bitcoin
with my UTS VM guest, you can cost me literally dozens of cents a month in
electricity, probably.

I have not played with the 3270 libraries, but they exist.  The two
full-screen 3270 utilities I am aware of are ned and man.  Ned's really
rather a lovely little editor.  Other than that it feels a lot like a stock
v7, but of course the terminal is linemode.  The command to log out is
"logoff".

Adam

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

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

[segaloco via TUHS]

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

Oh wow, this is cool. So I hopped on and am looking around, after digging around for a while, it looks like that version of UNIX is this: https://en.wikipedia.org/wiki/Amdahl_UTS

A very, very early version at that. Wikipedia says they stuck around and carried this through all the way to being an SVR4 derivative, but what we're seeing here, at least based on perusing around for 5-10 minutes, does indeed look very V7ish. The manual is interesting, looks like they tried to create their own manual ordering, there are man0-man3 folders but then vol1 vol2 and vol3 containing copies of many things, as well as several scripts and files with a lot of information on their process for adding new pages and documents. My reasoning on this not being past V7 is that there are no utsname or uname syscalls to speak of, nor pwbname. The history on that command/syscall is a little fuzzy, I know I've seen the name "utsname" somewhere but I can't recall where. The command is uname by the time of 3.0. This version does have a "sysname" command that suggests it does something similar, but I couldn't find a corresponding syscall, not that I looked very hard.

- Matt G.
------- Original Message -------
On Monday, December 19th, 2022 at 5:04 PM, Adam Thornton <athornton@gmail.com> wrote:

> If anyone wants to play with UTS--the version I'm running has sources that indicate it's pretty much a v7--you can connect to it at https://mvsevm.fsf.net, resize your window so the terminal is 80x25, pick option 11 (VM/370), hit enter, and then after the logo goes away type "DIAL UTS".
>
> The passwords are findable via a web search for something like "uts vm/370 password" in that I have not changed them from the defaults. If you manage to break out of UTS into VM, and from there into Hercules, and from that to the physical host, and then from there compromise my network, I'd like to know how you did it. If on the other hand you're going to mine bitcoin with my UTS VM guest, you can cost me literally dozens of cents a month in electricity, probably.
>
> I have not played with the 3270 libraries, but they exist. The two full-screen 3270 utilities I am aware of are ned and man. Ned's really rather a lovely little editor. Other than that it feels a lot like a stock v7, but of course the terminal is linemode. The command to log out is "logoff".
>
> Adam

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

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

[Andrew Hume]

when i worked on system iii and system v, we were certainly using SCCS
(and not sublime). we had some machinery built on top of SCCS but by and large,
it was just SCCS.

> On Dec 19, 2022, at 4:02 PM, Brad Spencer <brad@anduin.eldar.org> wrote:
> [snip]
> 
> Someone else will have to indicate if raw SCCS was used during the time
> frame for the code you are looking at or if there was some management
> system built on SCCS that was actually used.
> -- 
> Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org

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

[Clem Cole]

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

On Mon, Dec 19, 2022 at 4:20 PM Rob Pike <robpike@gmail.com> wrote:

> Quite a bit of this feels not exactly wrong, but not quite right. (And his
> name is John Reiser, not Reisner.)
>
Thank you.  Never assume I will get spelling right ;-)



> Steve Johnson didn't go to work in development until the mid 1980s, for
> example, long after these bloodlines as you call them were laid down.
>
Yes, I know.  I did not mean to imply this -- only that we have discussed
much of this and Steve has offered comments as a manager.



>
> Do we know that PWB became USG? That doesn't feel right to me, although it
> might well be true, I wasn't there.
>
I was not either, although very close friends with a few that were.  My old
lab partner in hacking, the late Ted Kowalski and Armando Stettner were
officemates in Summit in USG in the late 1970s - who are the primary
sources of data I have from that time.   Mashey is the other (and I think
we have an old email from John in the archives).

The problem you are getting too is exactly what I was referring BTW.  It
was not a straight line.

Some facts ... PWB 1.0 was created and release before USG would be
created.   Again look at the old messages here.   What I don't know is who
packaged PWB 2.0 -- I was under the impression that was still Mashey et al
(as you said Whippany a few other NJ labs - although the USG folks must
have just been created).

IIRC the kernel in PWB 2.0 and V7 are close, but not the same and
definitely the userspaces are different.

TS starts to could thing, and the best I personally can tell (again from
old message from Ted Armando et al), at some point TS was being created -
maybe around 1978ish.    How much of V7 went into TS and vice versa - is
not clear.  So far, I do not believe we have found a definitive TS
'distribution' - but a number of things seem to be a part.  Werner I think
can add the most color here, as he researched it., a bit more than I did.
Again, the best, I can tell is that something approximating TS 1.0 was
created (in Summit >>I believe<<) and it had a common kernel with V7.  Who
got it and how it was distributed it not completely understood -- again
AT&T politics, the consent decree et al, all mix this up.

Tick, tick, tick ...  Judge Green does his thing ...

PWB 3.0 was released to the OCs at some point.     During a
discussions AT&T NC (Al Arms et al) had with customers (like me), we had
memos created by USG that are marked PWB 3.0 that discussed what was going
to be in the release.  AT&T North Carolina (the lawyers and marketing
folks) gave them to us.    I personally was part of the
negotiation associated with that license had a few of those memos at one
point.   They were clearly marked PWB 3.0 and were originally created
the OCs distribution.

 AT&T was now in the computer market and the marketing/sales types and did
not like the name Programmmer Workbench - when going against IBM [who was
clearly the target].  It was also made clear to us (commercial UNIX
licensees) that whatever was produced, would not be the named PWBct when
the AT&T Marketing folks released it publically -- it seems to me that they
were working trademarking in parallel with the pricing/licensing
negotiation that I was a part.

I >>believe<< that is why the manuals were printed saying 3.0 - but Summit
did not yet know what the name would be - although they did release PWB 3.0
inside of the Bell System.   Eventually, the name 'System III' was picked
by AT&T NC and the marketing blitz started -- "Consider it standard," etc..

FWIW: John Mashey is the source of the comment about PWB bloodline begets
Summits work.





> I think of it as mostly staying in Whippany, not going to Summit. Also
> your prose would imply USG never got to V7 level, which is certainly not
> true.
>
Not at all.  I was not trying to imply that in any way.




> Columbus's major contribution, as we saw it from Research, was the world's
> second most complex init.
>
systemd was yet to be created ;-)




> All these variants lobbied to have Research adopt things, as such approval
> was seen as a badge of honor. Honestly, though, it was all pretty toxic.
>
That is the impression I had.



>
> Reiser and London's Unix, which I greatly admired, died on the vine for a
> variety of political reasons, as well as because it had slightly different
> semantics in some important cases, and because of a broad antipathy to
> virtual memory across the company due to various people having used VM on
> inadequate hardware, and of course then there was Multics.
>
Again - that syncs with my comments and my memory of the time.



> Sandy Fraser was very nervous about Research adopting the BSD kernel
> because of his experience with Atlas. But let it be said: Reiser's VM
> system was seriously impressive, cleanly integrated, structurally central,
> and wonderfully fast.
>
I never ran it, but that does seem to be the report.

Question for you Rob ... SVR3 was a rewrite the memory system from earlier
things called 'System V'.   Do you know if any of Reiser's stuff make it
into that or was SVR3 a new stream altogether and who did it?   Tom Bishop
lead me to believe that some of Reiser's stuff was imported into the SSI
system they did in IH. But again what went where and who did what has never
been clearly understood.

And that was my point -- there was never a linear progression.



> And Sandy relented but the general warmth of 1127 towards Berkeley led to
> Research adopting Berkeley Unix as its VAX VM platform, despite some,
> including myself, feeling that was the inferior choice.
>
Indeed and not the first time we have heard that said here.
ᐧ

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

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

[Larry Stewart]

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

I forget if I've mentioned this here before, so apologies in advance.

I never met Reiser, but I ran across his PhD thesis (for Knuth!).  It was 35 pages (!) on random number generators.  I implemented one for my own work.   It was pretty clear he was one of those people who is smarter than the rest of us.

-Larry

> On Dec 19, 2022, at 6:03 PM, Clem Cole <clemc@ccc.com> wrote:
> 
> 
> 
> 
>> On Mon, Dec 19, 2022 at 4:20 PM Rob Pike <robpike@gmail.com> wrote:
>> Quite a bit of this feels not exactly wrong, but not quite right. (And his name is John Reiser, not Reisner.)
> Thank you.  Never assume I will get spelling right ;-)
> 
>  
>> Steve Johnson didn't go to work in development until the mid 1980s, for example, long after these bloodlines as you call them were laid down.
> Yes, I know.  I did not mean to imply this -- only that we have discussed much of this and Steve has offered comments as a manager.
> 
>  
>> 
>> Do we know that PWB became USG? That doesn't feel right to me, although it might well be true, I wasn't there.
> I was not either, although very close friends with a few that were.  My old lab partner in hacking, the late Ted Kowalski and Armando Stettner were officemates in Summit in USG in the late 1970s - who are the primary sources of data I have from that time.   Mashey is the other (and I think we have an old email from John in the archives).
> 
> The problem you are getting too is exactly what I was referring BTW.  It was not a straight line.
> 
> Some facts ... PWB 1.0 was created and release before USG would be created.   Again look at the old messages here.   What I don't know is who packaged PWB 2.0 -- I was under the impression that was still Mashey et al (as you said Whippany a few other NJ labs - although the USG folks must have just been created).   
> 
> IIRC the kernel in PWB 2.0 and V7 are close, but not the same and definitely the userspaces are different.
> 
> TS starts to could thing, and the best I personally can tell (again from old message from Ted Armando et al), at some point TS was being created - maybe around 1978ish.    How much of V7 went into TS and vice versa - is not clear.  So far, I do not believe we have found a definitive TS 'distribution' - but a number of things seem to be a part.  Werner I think can add the most color here, as he researched it., a bit more than I did.  Again, the best, I can tell is that something approximating TS 1.0 was created (in Summit >>I believe<<) and it had a common kernel with V7.  Who got it and how it was distributed it not completely understood -- again AT&T politics, the consent decree et al, all mix this up.
> 
> Tick, tick, tick ...  Judge Green does his thing ...
> 
> PWB 3.0 was released to the OCs at some point.     During a discussions AT&T NC (Al Arms et al) had with customers (like me), we had memos created by USG that are marked PWB 3.0 that discussed what was going to be in the release.  AT&T North Carolina (the lawyers and marketing folks) gave them to us.    I personally was part of the negotiation associated with that license had a few of those memos at one point.   They were clearly marked PWB 3.0 and were originally created the OCs distribution. 
> 
>  AT&T was now in the computer market and the marketing/sales types and did not like the name Programmmer Workbench - when going against IBM [who was clearly the target].  It was also made clear to us (commercial UNIX licensees) that whatever was produced, would not be the named PWBct when the AT&T Marketing folks released it publically -- it seems to me that they were working trademarking in parallel with the pricing/licensing negotiation that I was a part. 
> 
> I >>believe<< that is why the manuals were printed saying 3.0 - but Summit did not yet know what the name would be - although they did release PWB 3.0 inside of the Bell System.   Eventually, the name 'System III' was picked by AT&T NC and the marketing blitz started -- "Consider it standard," etc..
> 
> FWIW: John Mashey is the source of the comment about PWB bloodline begets Summits work. 
> 
> 
> 
>  
>> I think of it as mostly staying in Whippany, not going to Summit. Also your prose would imply USG never got to V7 level, which is certainly not true.
> Not at all.  I was not trying to imply that in any way.
> 
> 
>  
>> Columbus's major contribution, as we saw it from Research, was the world's second most complex init.
> systemd was yet to be created ;-)
> 
> 
>  
>> All these variants lobbied to have Research adopt things, as such approval was seen as a badge of honor. Honestly, though, it was all pretty toxic.
> That is the impression I had.
> 
>  
>> 
>> Reiser and London's Unix, which I greatly admired, died on the vine for a variety of political reasons, as well as because it had slightly different semantics in some important cases, and because of a broad antipathy to virtual memory across the company due to various people having used VM on inadequate hardware, and of course then there was Multics.
> Again - that syncs with my comments and my memory of the time.
> 
>  
>> Sandy Fraser was very nervous about Research adopting the BSD kernel because of his experience with Atlas. But let it be said: Reiser's VM system was seriously impressive, cleanly integrated, structurally central, and wonderfully fast.
> I never ran it, but that does seem to be the report.
> 
> Question for you Rob ... SVR3 was a rewrite the memory system from earlier things called 'System V'.   Do you know if any of Reiser's stuff make it into that or was SVR3 a new stream altogether and who did it?   Tom Bishop lead me to believe that some of Reiser's stuff was imported into the SSI system they did in IH. But again what went where and who did what has never been clearly understood.
> 
> And that was my point -- there was never a linear progression.
> 
>  
>> And Sandy relented but the general warmth of 1127 towards Berkeley led to Research adopting Berkeley Unix as its VAX VM platform, despite some, including myself, feeling that was the inferior choice.
> Indeed and not the first time we have heard that said here. 
> ᐧ

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

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

[Larry McVoy]

On Mon, Dec 19, 2022 at 08:20:07PM -0500, Larry Stewart wrote:
> I forget if I've mentioned this here before, so apologies in advance.
> 
> I never met Reiser, but I ran across his PhD thesis (for Knuth!).  It was 35 pages (!) on random number generators.  I implemented one for my own work.   It was pretty clear he was one of those people who is smarter than the rest of us.

Rob's (and maybe other's?) description of the VM system he did makes me
really want to read that code.  Rob talked about it the way I talk about
the SunOS 4.x VM system, very clean and easy to understand.

I'm still waiting to hear someone talk about an SMP VM system that way.
That stuff gets complicated.

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

[George Michaelson]

Any comment now about taking ideas from Berkeley is informed by the
twisted history which followed. At the time I can totally understand a
preference for code from the tertiary education sector over IBM absent
some explicit decision higher up about IPR: dealing with IBM must have
been a very complicated story for Bell over time, and it wasn't that
long since the whole CP/M MS-DOS thing had blown up with sillyness on
both sides. It is entirely possible a decision with this much weight
was made on a hunch/feel at some desk who had suffered at the hands of
big blue lawyers at the time. Just because at a transatlantic distance
I found the regents a nightmare to deal with (4.1 to 4.2 upgrade,
re-licencing with bodies moving so signatures differing, then much
later the same dance over some VLSI design s/w at UQ in Australia)
doesn't mean Bell would have. To the contrary, they might have had the
lowest bar legal and contractual barriers to work with.

There was also the whole thing about DoD funding. Sockets are crap. I
think they only became a de-facto standard because of familiarity. But
again, put that back into historical context and have a platform
coming out of the Californian state education system funded by the DoD
with a network interface. DoD funding..yea lets hitch on that: maybe
there will be some more of that sweet DARPA money flowing and if we're
familiar with it, then we can get into the future contracts: Not that
anyone cutting code thinks that way but desk jockeys would maybe?

York Unix was how I met things on a Vax with VM. I remain a fan of how
Charles Forsyth codes things. Small and elegant. I don't know that it
fed back into anything.

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

[Dan Cross]

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

On Mon, Dec 19, 2022, 8:59 PM George Michaelson <ggm@algebras.org> wrote:

> [snip]
>
> York Unix was how I met things on a Vax with VM. I remain a fan of how
> Charles Forsyth codes things. Small and elegant. I don't know that it
> fed back into anything.
>

Forsyth wrote a really nice paper on the follow-on work he did on Sun's; he
implemented the EMAS paging algorithms, which was quite the coup.

        - Dan C.

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

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

[Chet Ramey]

On 12/19/22 9:06 PM, Dan Cross wrote:

>     York Unix was how I met things on a Vax with VM. I remain a fan of how
>     Charles Forsyth codes things. Small and elegant. I don't know that it
>     fed back into anything.
> 
> 
> Forsyth wrote a really nice paper on the follow-on work he did on Sun's; he 
> implemented the EMAS paging algorithms, which was quite the coup.

http://www.collyer.net/who/geoff/taste.pdf

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

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

[Adam Thornton]

I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support.

The third one is a solved problem.  The second one would not be that hard to adapt, say, uIP 0.9, to v7.  That first one would require some work with C type sizes, but getting larger is easier than the reverse.  It's that last one.

Having said that...maybe what I really want is 64-bit 4.3 BSD?

I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine.  I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host.

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

[Andy Kosela]

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

On Tuesday, December 20, 2022, Adam Thornton <athornton@gmail.com> wrote:

> I mean, just a Unix, without all the cruft of a modern Linux, but which
> can actually take advantage of the resources of a modern machine.  I don't
> care about a desktop, or even a graphical environment, I don't care about
> all the strange syscalls that are there to support particular databases, I
> don't care much about being a virtualization host.


But then...what would the purpose of such a system? A mini-Unix just to run
vi(1) or text based game? If you want to run retro games there are much
better retro platforms for that, e.g. I do not need a Unix machine if I
want to run MS-DOS era games. I prefer period correct hardware and software.

If you want a modern Unix for production systems, then most of the real
world modern workloads are run in Kubernetes which is a very Linux
orientated technology anyway.

It appears to me there is really no need for such a modern mini-Unix system
outside of hard core O/S theorists community.

There are already a myriad of similar projects like Alan Cox's Fuzix OS
which can run e.g. on Amiga, but it will not play Centurion or Another
World anytime soon anyway.

--Andy

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

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

[Adam Thornton]

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

On Tue, Dec 20, 2022 at 8:29 AM Andy Kosela <akosela@andykosela.com> wrote:

> On Tuesday, December 20, 2022, Adam Thornton <athornton@gmail.com> wrote:
>
>> I mean, just a Unix, without all the cruft of a modern Linux, but which
>> can actually take advantage of the resources of a modern machine.  I don't
>> care about a desktop, or even a graphical environment, I don't care about
>> all the strange syscalls that are there to support particular databases, I
>> don't care much about being a virtualization host.
>
>
> But then...what would the purpose of such a system? ...
> It appears to me there is really no need for such a modern mini-Unix
> system outside of hard core O/S theorists community.
>
>
I'm not asking for a _practical_ Christmas gift, and certainly not one that
will help me at work.  As you say: at work I've got Kubernetes.  I think it
would be aesthetically pleasing and fun to use.  Need has nothing to do
with it.

Adam

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

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

[Luther Johnson]

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

I'm in the process of building a system like that for myself, but 
perhaps a little smaller - mine will be based on an embedded 
microprocessor I've developed (so much work still yet to do ! at least a 
year out). But are you familiar with the V7 port that Robert Nordier has 
done ? It's been mentioned here before:

https://minnie.tuhs.org/pipermail/tuhs/2007-October/004782.html

Here is his web site:

https://edu.anarcho-copy.org/UNIX/unix-version-7/x86-port/www.nordier.com/v7x86/

On 12/20/2022 08:35 AM, Adam Thornton wrote:
>
>
> On Tue, Dec 20, 2022 at 8:29 AM Andy Kosela <akosela@andykosela.com 
> <mailto:akosela@andykosela.com>> wrote:
>
>     On Tuesday, December 20, 2022, Adam Thornton <athornton@gmail.com
>     <mailto:athornton@gmail.com>> wrote:
>
>         I mean, just a Unix, without all the cruft of a modern Linux,
>         but which can actually take advantage of the resources of a
>         modern machine.  I don't care about a desktop, or even a
>         graphical environment, I don't care about all the strange
>         syscalls that are there to support particular databases, I
>         don't care much about being a virtualization host.
>
>
>     But then...what would the purpose of such a system? ...
>     It appears to me there is really no need for such a modern
>     mini-Unix system outside of hard core O/S theorists community.
>
>
> I'm not asking for a _practical_ Christmas gift, and certainly not one 
> that will help me at work.  As you say: at work I've got Kubernetes.  
> I think it would be aesthetically pleasing and fun to use.  Need has 
> nothing to do with it.
>
> Adam


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

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

[David Arnold]

> On 20 Dec 2022, at 13:12, Adam Thornton <athornton@gmail.com> wrote:
> 
> I mean all I really want for Christmas is a 64-bit v7 with TCP/IP support, a screen editor, and SMP support.
> 
> The third one is a solved problem.  The second one would not be that hard to adapt, say, uIP 0.9, to v7.  That first one would require some work with C type sizes, but getting larger is easier than the reverse.  It's that last one.
> 
> Having said that...maybe what I really want is 64-bit 4.3 BSD?
> 
> I mean, just a Unix, without all the cruft of a modern Linux, but which can actually take advantage of the resources of a modern machine.  I don't care about a desktop, or even a graphical environment, I don't care about all the strange syscalls that are there to support particular databases, I don't care much about being a virtualization host.


I think xv6 does SMP?  (param.h says NCPU = 8, at least).

You’d need to add a network stack and a userland, but there are options for those …




d

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

[Bakul Shah]

On Dec 19, 2022, at 1:19 PM, Rob Pike <robpike@gmail.com> wrote:
> 
> Reiser and London's Unix, which I greatly admired, died on the vine
> for a variety of political reasons, as well as because it had
> slightly different semantics in some important cases, and because
> of a broad antipathy to virtual memory across the company due to
> various people having used VM on inadequate hardware, and of course 
> then there was Multics. Sandy Fraser was very nervous about
> Research adopting the BSD kernel because of his experience with
> Atlas. But let it be said: Reiser's VM system was seriously
> impressive, cleanly integrated, structurally central, and
> wonderfully fast. And Sandy relented but the general warmth of 1127
> towards Berkeley led to Research adopting Berkeley Unix as its VAX
> VM platform, despite some, including myself, feeling that was 
> inferior choice.

Is there a publicly available description of Reiser's VM system?
I found "A Unix operating system for the DEC VAX 11/780 Computer"
by London & Reiser which includes a long paragraph on VM (included
below) but that is about it.

And it would be interesting to hear why and what you found in
Reiser's VM system that was better than Berkeley's VM system.

Thanks!

From the London&Reiser paper:
    The virtual address space of a process running on the
VAX-11/780 consists of 2**32 8-bit bytes.  The two high-order
bits of a 32-bit address determine one of four segments. Two
of these segments are system segments common to the address
space of all processes. One of the system segments is
reserved for future use. The other two segments are
separately defined for each process and are automatically
managed by the context switching instructions. One of the
per-process segments is designed for a stack which grows
towards lower-numbered memory addresses. Segments are divided
into pages of 512 bytes. Memory mapping hardware translates
virtual addresses into physical addresses using page tables.
A page table contains one four-byte entry for each page
mapped; the entry contains a valid bit, a four-bit field
which encodes access privileges, a modify bit, and the
physical page-frame number where the page is mapped. (There
is no reference bit which is maintained by hardware!) A base
register and a limit register describe the page table of each
segment. The base register of a per-process segment contains
a virtual address within the system segment; the base
register for the system segment contains a physical memory
address. The VAX11/780 central processor contains a virtual
address translation buffer holding 128 virtual address-page
frame number pairs which eliminates the need for extra memory
references during address translation for (typically) 9896 of
all memory references. The memory is implemented using MOS
semiconductor RAMs with an error correcting code which
corrects all single-bit errors and detects all double-bit
errors and 70% of all greater-than-double bit errors. A
memory controller can handle 8 memory boards; using 4K chips
each board can hold 128K bytes. There can be two memory
controllers, thus the maximum amount of physical memory is
currently 2 megabytes. When 16K chips are used (forecasted
for late 1978), each board will hold 512K, and physical
memory can be 8 megabytes. There is a battery backup option
for maintaining data in the event of a power failure. Each
optional battery will maintain l megabyte for 10 minutes.

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

[Larry McVoy]

On Mon, Dec 19, 2022 at 06:52:47PM -0800, Bakul Shah wrote:
> On Dec 19, 2022, at 1:19 PM, Rob Pike <robpike@gmail.com> wrote:
> > 
> > Reiser and London's Unix, which I greatly admired, died on the vine
> > for a variety of political reasons, as well as because it had
> > slightly different semantics in some important cases, and because
> > of a broad antipathy to virtual memory across the company due to
> > various people having used VM on inadequate hardware, and of course 
> > then there was Multics. Sandy Fraser was very nervous about
> > Research adopting the BSD kernel because of his experience with
> > Atlas. But let it be said: Reiser's VM system was seriously
> > impressive, cleanly integrated, structurally central, and
> > wonderfully fast. And Sandy relented but the general warmth of 1127
> > towards Berkeley led to Research adopting Berkeley Unix as its VAX
> > VM platform, despite some, including myself, feeling that was 
> > inferior choice.
> 
> Is there a publicly available description of Reiser's VM system?
> I found "A Unix operating system for the DEC VAX 11/780 Computer"
> by London & Reiser which includes a long paragraph on VM (included
> below) but that is about it.
> 
> And it would be interesting to hear why and what you found in
> Reiser's VM system that was better than Berkeley's VM system.

Berkeley didn't really have a good VM system, other than Bill Joy
imagining it and then went on to go to Sun and inspired Joe Moran
to implement it.

FreeBSD took Mach's VM system and while I have respect for what 
Mach was trying to do, holy moly, what a mess.

I can't speak to Reiser's code because I haven't seen it, but I 
can speak to Joe Moran's code, it was just so clear to see what
he was trying to do.  And he did it.  And you could understand it,
I did as a year out of grad school.

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

[Bakul Shah]

On Dec 19, 2022, at 7:09 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> Berkeley didn't really have a good VM system, other than Bill Joy
> imagining it and then went on to go to Sun and inspired Joe Moran
> to implement it.

The context I was interested in is the VAX and early 80s.
The following paper by Özalp Baboğlu & Bill Joy describes
the BSD design in some detail.

http://roguelife.org/~fujita/COOKIES/HISTORY/3BSD/design.pdf

> FreeBSD took Mach's VM system and while I have respect for what 
> Mach was trying to do, holy moly, what a mess.

FreeBSD came much later. 1994 or so. 

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

[Warner Losh]

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

On Mon, Dec 19, 2022, 8:10 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Mon, Dec 19, 2022 at 06:52:47PM -0800, Bakul Shah wrote:
> > On Dec 19, 2022, at 1:19 PM, Rob Pike <robpike@gmail.com> wrote:
> > >
> > > Reiser and London's Unix, which I greatly admired, died on the vine
> > > for a variety of political reasons, as well as because it had
> > > slightly different semantics in some important cases, and because
> > > of a broad antipathy to virtual memory across the company due to
> > > various people having used VM on inadequate hardware, and of course
> > > then there was Multics. Sandy Fraser was very nervous about
> > > Research adopting the BSD kernel because of his experience with
> > > Atlas. But let it be said: Reiser's VM system was seriously
> > > impressive, cleanly integrated, structurally central, and
> > > wonderfully fast. And Sandy relented but the general warmth of 1127
> > > towards Berkeley led to Research adopting Berkeley Unix as its VAX
> > > VM platform, despite some, including myself, feeling that was
> > > inferior choice.
> >
> > Is there a publicly available description of Reiser's VM system?
> > I found "A Unix operating system for the DEC VAX 11/780 Computer"
> > by London & Reiser which includes a long paragraph on VM (included
> > below) but that is about it.
> >
> > And it would be interesting to hear why and what you found in
> > Reiser's VM system that was better than Berkeley's VM system.
>
> Berkeley didn't really have a good VM system, other than Bill Joy
> imagining it and then went on to go to Sun and inspired Joe Moran
> to implement it.
>

The 4.2 and 4.3 VM were too vax specific.

FreeBSD took Mach's VM system and while I have respect for what
> Mach was trying to do, holy moly, what a mess.
>

To be fair, 4.4BSD had the mach vm because while Sun wanted to donate their
VM, the lawyers killed the deal due to its value to the company... I'd sure
rather have had the SunOS vm in 4.4BSD, but they went with what was
available.  The Mach VM works, but it's fit to the 4.4 kernel is imperfect.

FreeBSD made it work via the early heroics of Dyson and Dillon, and the
late SMP tuning of Juniper. It works, but has undergone at least 5 or 6
reorgs over the years. It also scales as all the bottlenecks have been
fixed... but it could sure stand a rewrite (though that will have to wait
for the next paradigm shift).

NetBSD and OpenBSD adopted uvm instead maybe 5 or 10 years after 4.4 was
released. This VM was initially more easily scaleable than Mach, but I'm
not sure the vastly increased core counts of late work well with it.

Warner

I can't speak to Reiser's code because I haven't seen it, but I
> can speak to Joe Moran's code, it was just so clear to see what
> he was trying to do.  And he did it.  And you could understand it,
> I did as a year out of grad school.
>

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

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

[Jonathan Gray]

On Mon, Dec 19, 2022 at 07:09:43PM -0800, Larry McVoy wrote:
> 
> Berkeley didn't really have a good VM system, other than Bill Joy
> imagining it and then went on to go to Sun and inspired Joe Moran
> to implement it.
> 
> FreeBSD took Mach's VM system and while I have respect for what 
> Mach was trying to do, holy moly, what a mess.

Mike Hibler did that for HPBSD and CSRG releases.

https://www.flux.utah.edu/~mike/hpbsd/hpbsd.html

"In April 1989, with encouragement from CSRG, I started the
``new VM project,'' integrating the Mach 2.0 VM system[1] into BSD. This
was done in the context of our then current HPBSD. A reasonable
prototype was done by November 1989 when I talked about it at the
``Berkeley workshop'' in Boulder[2]. Development on the new VM code in
HPBSD continued off and on til May of 1990 when the VM code was merged
into CSRG's source tree (what was to become net2 and later 4.4bsd)."

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

[Marc Donner]

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

There was a track of USENIX 1986 called "UNIX on Big Iron."  Peter Capek of
IBM was the chair and Gene Miya and Jim Lipkis rounded out the program
committee.  The proceedings are available.

Program included:

   - User Requirements for Future-nix - Gene Miya
   - Experience with Large Applications on UNIX - Bob Bilyeu
   - UNIX Scheduling for Large Systems - Jeffrey Straathof, Ashok Thareja,
   Ashok Agrawal
   - A Straightforward Implementation of a 4.2BSD on a High Performance
   Multiprocessor - Dave Probert
   - Porting UNIX to the System/370 Extended Architecture - Joseph R Eykholt
   - Full Duplex Support for Mainframes - Don Sterk
   - Concentrix -- A UNIX for the Alliant Multiprocessor - Jack Test
   - A User-Tunable Multiprocessor Schedule - Herb Jacobs
   - Considerations for Massively Parallel UNIX Systems on the NYU
   Ultracomputer and the IBM RP3 - Jan Edler, Alan Jottlieb, Jim Lipkis
   - UNIX of CTSS for the Cray-1, Cray X-MP, and Cray-2 Supercomputers -
   Karl Auerbach, Robin O'Neill
   - Experience Porting System V to the Cray 2 - Tim Hoel

=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>


On Mon, Dec 19, 2022 at 12:38 PM Phil Budne <phil@ultimate.com> wrote:

> The October 1984 BSTJ article by Felton, Miller and Milner
> https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
>
> Describes an AT&T port of UNIX to System/370 using TSS/370
> underpinnings as the "Resident System Supervisor" and used as the 5ESS
> switching system development environment.
>
> I also found mention at http://www.columbia.edu/~rh120/ch106.x09
> chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96:
>
>       Ian Johnstone, who had been the tutor at University of New
>       South Wales working with Professor John Lions, was one of the
>       researchers invited to Bell Labs. He managed the completion at
>       AT&T Bell Labs of the port of Unix to the IBM 370 computer. See
>       "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX
>       Review, October, 1984, p. 26. Johnstone also led the group that did
>       the port to the AT&T 2B20A multiprocessor system.
>
> I found
>
> https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf
> "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers
> rationale.
>
> Also:
>
>         "IBM's own involvement in Unix can be dated to 1979, when it
>         assisted Bell Labs in doing its own Unix port to the 370 (to
>         be used as a build host for the 5ESS switch's software). In
>         the process, IBM made modifications to the TSS/370 hypervisor
>         to better support Unix.[12]"
> at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0
>
> Is there any other surviving documentation about the system?
> Any recall of what branch of AT&T UNIX it was based on?
>
> Thanks!
> Phil
>
>

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

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

[Charles H Sauer (he/him)]

Locus Computing Corporation had a substantial Unix on 370 effort in the 
1980s.

My impression/understanding was that the LCC kernel was derived from 
4.1BSD and close to the metal when running on the 370.

The LCC work became AIX/370 & AIX PS/2 with the Locus distributed system 
technology named TCF (transparent computing facility).

As far as I know, the LCC work that became AIX/370 was the only version 
of Unix for the 370 officially supported by IBM.

On 12/19/2022 3:36 PM, Marc Donner wrote:
> There was a track of USENIX 1986 called "UNIX on Big Iron."  Peter Capek 
> of IBM was the chair and Gene Miya and Jim Lipkis rounded out the 
> program committee.  The proceedings are available.
> 
> Program included:
> 
>   * User Requirements for Future-nix - Gene Miya
>   * Experience with Large Applications on UNIX - Bob Bilyeu
>   * UNIX Scheduling for Large Systems - Jeffrey Straathof, Ashok
>     Thareja, Ashok Agrawal
>   * A Straightforward Implementation of a 4.2BSD on a High Performance
>     Multiprocessor - Dave Probert
>   * Porting UNIX to the System/370 Extended Architecture - Joseph R Eykholt
>   * Full Duplex Support for Mainframes - Don Sterk
>   * Concentrix -- A UNIX for the Alliant Multiprocessor - Jack Test
>   * A User-Tunable Multiprocessor Schedule - Herb Jacobs
>   * Considerations for Massively Parallel UNIX Systems on the NYU
>     Ultracomputer and the IBM RP3 - Jan Edler, Alan Jottlieb, Jim Lipkis
>   * UNIX of CTSS for the Cray-1, Cray X-MP, and Cray-2 Supercomputers -
>     Karl Auerbach, Robin O'Neill
>   * Experience Porting System V to the Cray 2 - Tim Hoel
> 
> =====
> nygeek.net <http://nygeek.net>
> mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>
> 
> 
> On Mon, Dec 19, 2022 at 12:38 PM Phil Budne <phil@ultimate.com 
> <mailto:phil@ultimate.com>> wrote:
> 
>     The October 1984 BSTJ article by Felton, Miller and Milner
>     https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
>     <https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf>
> 
>     Describes an AT&T port of UNIX to System/370 using TSS/370
>     underpinnings as the "Resident System Supervisor" and used as the 5ESS
>     switching system development environment.
> 
>     I also found mention at http://www.columbia.edu/~rh120/ch106.x09
>     <http://www.columbia.edu/~rh120/ch106.x09>
>     chapter 9 of http://www.columbia.edu/~rh120/
>     <http://www.columbia.edu/~rh120/> with footnote 96:
> 
>            Ian Johnstone, who had been the tutor at University of New
>            South Wales working with Professor John Lions, was one of the
>            researchers invited to Bell Labs. He managed the completion at
>            AT&T Bell Labs of the port of Unix to the IBM 370 computer. See
>            "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX
>            Review, October, 1984, p. 26. Johnstone also led the group
>     that did
>            the port to the AT&T 2B20A multiprocessor system.
> 
>     I found
>     https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf <https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf>
>     "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers
>     rationale.
> 
>     Also:
> 
>              "IBM's own involvement in Unix can be dated to 1979, when it
>              assisted Bell Labs in doing its own Unix port to the 370 (to
>              be used as a build host for the 5ESS switch's software). In
>              the process, IBM made modifications to the TSS/370 hypervisor
>              to better support Unix.[12]"
>     at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0
>     <https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0>
> 
>     Is there any other surviving documentation about the system?
>     Any recall of what branch of AT&T UNIX it was based on?
> 
>     Thanks!
>     Phil
> 

-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/Twitter: CharlesHSauer

[TUHS] Re: pre-1991 USENIX proceedings

[Marc Donner]

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

https://bitsavers.org/pdf/usenix/USENIX_1986_Winter_Technical_Conference_Proceedings_198601.pdf

Here is the URL

(All I did was search for ‘“Unix on big iron” usenix proceedings’)

On Mon, Dec 19, 2022 at 4:59 PM James Frew <frew@ucsb.edu> wrote:

> Hello Marc,
>
> Where did you find the 1986 USENIX proceedings?
>
> Reason I'm asking is, I have a pile of pre-1991 USENIX proceedings that I
> haven't found online, and I'm planning to get them scanned. It would be
> great if I didn't have to go the trouble :-)
>
> Thanks,
> /James Frew
> On 2022-12-19 13:36, Marc Donner wrote:
>
>
> There was a track of USENIX 1986 called "UNIX on Big Iron."  Peter Capek
> of IBM was the chair and Gene Miya and Jim Lipkis rounded out the program
> committee.  The proceedings are available.
>
> --
=====
nygeek.net
mindthegapdialogs.com/home <https://www.mindthegapdialogs.com/home>

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

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

[Warner Losh]

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

On Mon, Dec 19, 2022, 10:39 AM Phil Budne <phil@ultimate.com> wrote:

> The October 1984 BSTJ article by Felton, Miller and Milner
> https://www.bell-labs.com/usr/dmr/www/otherports/ibm.pdf
>
> Describes an AT&T port of UNIX to System/370 using TSS/370
> underpinnings as the "Resident System Supervisor" and used as the 5ESS
> switching system development environment.
>
> I also found mention at http://www.columbia.edu/~rh120/ch106.x09
> chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96:
>
>       Ian Johnstone, who had been the tutor at University of New
>       South Wales working with Professor John Lions, was one of the
>       researchers invited to Bell Labs. He managed the completion at
>       AT&T Bell Labs of the port of Unix to the IBM 370 computer. See
>       "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX
>       Review, October, 1984, p. 26. Johnstone also led the group that did
>       the port to the AT&T 2B20A multiprocessor system.
>
> I found
>
> https://ia902801.us.archive.org/3/items/Unix_Review_1984_Oct.pdf/Unix_Review_1984_Oct.pdf
> "BIG UNIX: The Whys and Wherefores" (pdf p.24), which only offers
> rationale.
>
> Also:
>
>         "IBM's own involvement in Unix can be dated to 1979, when it
>         assisted Bell Labs in doing its own Unix port to the 370 (to
>         be used as a build host for the 5ESS switch's software). In
>         the process, IBM made modifications to the TSS/370 hypervisor
>         to better support Unix.[12]"
> at https://en.wikipedia.org/wiki/IBM_AIX#cite_ref-att-s370-unix_12-0
>
> Is there any other surviving documentation about the system?
> Any recall of what branch of AT&T UNIX it was based on?
>

[ since this original question hasn't been answered ]

>
V6. There were 3 v6 ports: two interdata ports (Wollongong and Labs) and
one VM/370 port (at Harvard or Princeton). They are got to first boot the
sane year, within a few months of each other

Uts grew out of this early port. There's several blog posts about this and
the TUHS archive has the initial port that was recovered from DECtapes
recently.

https://akapugs.blog/2018/05/12/370unixpart3/ is the last in the series.

AT&T also did a V7 port, which I think is what is written up in the bell
labs journal. I'm not sure I have a proper source for this other than
comparing the two accounts. I don't know if research did this or another
group.

AT&T did the VAX port of V7 called V32,  but v32 was little more than a
swapping kernel that didn't do demand paging. This is where the Berkeley
folks started to do paging with 3BSD. It is also where AT&T did their Vax
port that other mailing list threads chronicled.

Warner

>

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

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

[arnold]

Phil Budne <phil@ultimate.com> wrote:

> Is there any other surviving documentation about the system?
> Any recall of what branch of AT&T UNIX it was based on?

IIRC, in the USG 4.0 doc that I sent to Matt, it says something like
"UNIX is an operating system for the DEC PDP-11, the DEC VAX 11/780,
and the IBM System 370".  Matt --- can you confirm?  I can't get to my
copy so easily.

That document dates from 1981, and as it came from USG, it would mean
that the AT&T UNIX on 370 was from that world and is what is described
in the 1984 BSTJ.

If anyone has the System III source handy, one could check if there
is a u370 shell script and/or a u370 directory in the kernel source.
(There used to be shell scripts named pdp11, vax, u3b, and u370 for use
in shell 'if' statements, analogous to the C preprocessor defines.)
If so, then UNIX 370 would date back even further.

HTH,

Arnold

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

[segaloco via TUHS]

Looooots of if(n)defs in userland on "u370" in PDP-11 System V code, zilch on 3.0.1.

Yep, must've been 4.0, because that's in the first document, A.1.1: https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/A.1.1_Overview_and_Synopsis_of_Facilities.pdf

"Currently, UNIX runs on the Western Electric Co. 3B-20; Digital Equipment Corporation's (DEC) PDP-11/23, /34, /45, /70, VAX-11/780, and VAX-11/750; and IBM System/370 and equivalent."

But wait, there's more!

https://archive.org/details/unix-system-release-description-system-v

This is the Release Description released with System V.  It contains a couple of introductory documents explaining the new features and general environmental adjustments involved, as well as a number of appendices that make up the bulk of the document.  Of particular note in this case is Appendix I, the document I mentioned earlier containing a list of modification requests resolved between System III and System V.

Then there's the Documentation Guide: https://bitsavers.org/pdf/att/000-111_ATT_Documentation_Guide_Nov87.pdf

This is where mention is made of many different architectures.  There are documents for 3B20(A|S), 3B5, 3B15, 3B2, WE32100, VME/WE321SB, DEC (PDP/VAX), NS32000, M68000, iAPX 286, and Z8000.  This document also mentions docs for UNIX Real-Time-Reliable on the 3B20D.  No doubt a MERT and UNIX/RT descendant.  3B5 section mentions a "Release 5.3" so before the System V moniker.  Farthest I've seen the minor version.

I've skimmed over this listing a couple of times looking for other information but a few things stood out this time.  The WE321SB seems to be a single board computer running a version called System V/VME.  I wonder if any of those still exist, a single board running SVR2 out of the box!  No mention of System/370 though, but of course this is just a listing of available documentation at the time, it doesn't reflect what is actually out there.  Of the listed architectures, I don't think I've seen anything floating around for VME/WE321SB, Z8000, or iAPX 286, but I can't say I've looked very hard.

Needless to say the system really grew legs in the 80s even inside the Bell.

- Matt G.

------- Original Message -------
On Tuesday, December 20th, 2022 at 12:56 AM, arnold@skeeve.com <arnold@skeeve.com> wrote:


> Phil Budne phil@ultimate.com wrote:
> 
> > Is there any other surviving documentation about the system?
> > Any recall of what branch of AT&T UNIX it was based on?
> 
> 
> IIRC, in the USG 4.0 doc that I sent to Matt, it says something like
> "UNIX is an operating system for the DEC PDP-11, the DEC VAX 11/780,
> and the IBM System 370". Matt --- can you confirm? I can't get to my
> copy so easily.
> 
> That document dates from 1981, and as it came from USG, it would mean
> that the AT&T UNIX on 370 was from that world and is what is described
> in the 1984 BSTJ.
> 
> If anyone has the System III source handy, one could check if there
> is a u370 shell script and/or a u370 directory in the kernel source.
> (There used to be shell scripts named pdp11, vax, u3b, and u370 for use
> in shell 'if' statements, analogous to the C preprocessor defines.)
> If so, then UNIX 370 would date back even further.
> 
> HTH,
> 
> Arnold

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

[arnold]

segaloco <segaloco@protonmail.com> wrote:

> Looooots of if(n)defs in userland on "u370" in PDP-11 System V code, zilch on 3.0.1.
>
> Yep, must've been 4.0, because that's in the first document, A.1.1:
> https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/A.1.1_Overview_and_Synopsis_of_Facilities.pdf
> 
> "Currently, UNIX runs on the Western Electric Co. 3B-20; Digital Equipment
> Corporation's (DEC) PDP-11/23, /34, /45, /70, VAX-11/780, and VAX-11/750;
> and IBM System/370 and equivalent."

So there we have it, Unix/370 inside the Bell System was at 4.0.  I don't think they ever released that
outside the Bell System. Not surprising, as it needed a modified TSS underneath.

Arnold

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

[Jonathan Gray]

On Tue, Dec 20, 2022 at 02:39:52AM -0700, arnold@skeeve.com wrote:
> segaloco <segaloco@protonmail.com> wrote:
> 
> > Looooots of if(n)defs in userland on "u370" in PDP-11 System V code, zilch on 3.0.1.
> >
> > Yep, must've been 4.0, because that's in the first document, A.1.1:
> > https://www.tuhs.org/Archive/Documentation/Manuals/Unix_4.0/Volume_1/A.1.1_Overview_and_Synopsis_of_Facilities.pdf
> > 
> > "Currently, UNIX runs on the Western Electric Co. 3B-20; Digital Equipment
> > Corporation's (DEC) PDP-11/23, /34, /45, /70, VAX-11/780, and VAX-11/750;
> > and IBM System/370 and equivalent."
> 
> So there we have it, Unix/370 inside the Bell System was at 4.0.  I don't think they ever released that
> outside the Bell System. Not surprising, as it needed a modified TSS underneath.
> 
> Arnold

"A Bell Laboratories -wide reorganisation in January 1981 resulted in
the UNIX Lab being renumbered.  Release 4.0 was launched from this
organization in March. It introduced new IPC mechanisms as well as new
drivers and changes to the text processing software and the C libraries
etc.  Also in March, the first UNIX release for an IBM machine was
launched as UNIX/370 Release 3.0"

Pirzada, A Statistical Examination of The Evolution of the UNIX System
https://spiral.imperial.ac.uk/bitstream/10044/1/7942/1/Shamim_Sharfuddin_Pirzada-1988-PhD-Thesis.pdf

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

[Clem Cole]

[-- 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 --]

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

[Rob Gingell]

Some additional contextual notes largely in support of Clem's observations:

On 12/20/22 6:27 AM, Clem Cole wrote:
> 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. 
...
> 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, 
I said "largely in support" because have to contradict something first. 
The Sun VM system wasn't thrown out in SVR4, it was incorporated into 
SVR4, as were all of Sun's significant systems technologies through 
SunOS 4.0. (Which isn't to dismiss Larry's grievances over SVR4 as well 
as later changes corrupting to the VM system to support ZFS, simply to 
put them in the timeline correctly.)

That the AT&T/Sun SVR4 project happened at all had as its backdrop 
AT&T's desire to enter the computer business in a big way. AT&T had 
hired Vittorio Cassoni to run its computer division and he supplied 
significant energy towards the relationship with Sun (the word "pursuit" 
seemed applicable at the time). The impression I had was that this was 
part of trying to move quickly, one of probably several initiatives to 
gain a foothold in the industry. An alliance with a then red-hot company 
like Sun was perceived to serve that. People who were at Summit or 
within AT&T likely have a better and more complete cause-and-effect history.

The alliance was over more than UNIX as it anticipated AT&T employing 
SPARC processors and gaining a "platform presence". To Clem's point 
though, the alliance meant both organizations had to make concessions. 
In this particular case Sun didn't have to concede its existing systems 
work such as the VM system as that was all adopted in SVR4, but did have 
to concede what our plans would have been without the alliance. I can't 
speak to USG/Summit's concession but I'm very aware that our imposition 
on them was ... disruptive.

The press release jointly issued by both companies announcing the 
alliance, when read in the context of "AT&T is getting into the computer 
business" may add perspective. The release is appended below, though 
reading it 35 years later and knowing the outcome is also an interesting 
perspective and an illustration that "optimism" is also a party to most 
new relationships,

====

FOR RELEASE MONDAY, OCTOBER 19, 1987

NEW YORK, NY -- AT&T and Sun Microsystems, Inc., today unveiled plans
for a computer platform that will be unsurpassed in its ability to
protect customers' software investments, while allowing them to take
full advantage of technological innovation.

"This is the wave of the future," said Vittorio Cassoni, president of
AT&T's Data Systems Group.  "We expect this platform to become a major
computing environment for the 1990's and beyond."

The new platform will use a unified version of AT&T's UNIX    System V,
as well as Sun's recently announced Scalable Processor Architecture
(SPARC*), a flexible microprocessor design for chips that use reduced
instruction-set computing (RISC) technology.  It will include a
standard interface, known as an application binary interface, or ABI,
which will run UNIX system software programs as interchangeably as
personal computers run PC software today.

"Customers are demanding freedom of choice and easy access to new
technology--needs that only the UNIX system can meet," said Cassoni.
"That is why AT&T is making a concerted effort to consolidate the UNIX
system market."

UNIX System V for the new platform will incorporate popular features of
the Berkeley 4.2 system, a derivative of the UNIX system used widely in
scientific and engineering markets, as well as features of SunOS*, a
variant of the Berkeley 4.2 systems marketed by Sun.  These features
include networking and graphics features, such as the Network File
System (NFS*) and X.11/NeWS*, a graphic user interface.

Earlier this year, AT&T and Microsoft Corporation agreed to incorporate
the features of Microsoft's XENIX** into UNIX System V.

"Our agreement with Microsoft solidified the UNIX system market for
computers that use the Intel 80386 microprocessor, just as today's
agreement defines the UNIX system market for RISC computers," said
Cassoni.

"It's clear that the next generation of computers will be based on RISC
technology," said Scott McNealy, president and chief executive officer
of Sun Microsystems.  "The safest investments today are computers based
on the UNIX system.  The UNIX system is the only environment that can
ride the technology curve to RISC.

"The SPARC architecture is capturing widespread interest in the
industry," said McNealy.  "With UNIX System V and the ABI, SPARC
systems will give customers a powerful, open alternative to the
proprietary computing environments that, in effect, discourage
innovation and growth."

The SPARC architecture is gaining acceptance among RISC chip
manufacturers, since it can be transferred, or scaled, easily to new,
more powerful semiconductor technologies.  SPARC technology already has
been licensed to Fujitsu Microelectronics Inc., Cypress Semiconductor
Corp., and Bipolar Integrated Technology, Inc., for manufacture.

Sun markets the Sun-4* supercomputing workstation, which is based on a
SPARC implementation from Fujitsu.

"AT&T will add SPARC-based computers to its product line," Cassoni
said.  "And since our 3B computers and 6386 WorkGroup Systems are based
on UNIX System V, our customers who require high-performance computers
will be able to migrate easily to SPARC-RISC technology while
protecting their current and future investments in 3B and 6386 software
and system training."

The new platform will be created in phases.  By mid-1988, Sun will make
available a version of SunOS that will conform to AT&T's System V
Interface Definition.  In 1989, AT&T will offer UNIX System V
incorporating key Berkeley 4.2 system and SunOS features.  AT&T, with
Sun and others in the industry, then will continue to develop the
technology to be incorporated into the UNIX system to meet the market
needs of the 1990's.

AT&T and Sun will offer the new platform in their product lines.  In
addition, AT&T will license the software technology and Sun will
license the SPARC architecture to other manufacturers.

                              ###

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

[Andrew Hume]

i used to work for ianj (his login), and in fact, he persuaded bell labs to hire me from australia.
he had been my boss at the australian graduate school of management.
i think jon lions induced bell labs to interview ian for a job.
ian has retired and lives in rural victoria (australia), i think.
i occasionally have an alumni zoom conference with him.

ian caused a kerfuffle with bell labs. he was so good at his job that bell labs
wanted to promote him to supervisor but at the time, he
was still on a visitor (j-1) visa.

> On Dec 19, 2022, at 9:38 AM, Phil Budne <phil@ultimate.com> wrote:
> 
> I also found mention at http://www.columbia.edu/~rh120/ch106.x09
> chapter 9 of http://www.columbia.edu/~rh120/ with footnote 96:
> 
>      Ian Johnstone, who had been the tutor at University of New
>      South Wales working with Professor John Lions, was one of the
>      researchers invited to Bell Labs. He managed the completion at
>      AT&T Bell Labs of the port of Unix to the IBM 370 computer. See
>      "Unix on Big Iron" by Ian Johnstone and Steve Rosenthal, UNIX
>      Review, October, 1984, p. 26. Johnstone also led the group that did
>      the port to the AT&T 2B20A multiprocessor system.
> 
> Thanks!
> Phil
>