The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@minnie.tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)
Date: Fri,  6 May 2022 11:33:17 -0400 (EDT)	[thread overview]
Message-ID: <20220506153317.D499D18C07A@mercury.lcs.mit.edu> (raw)

    > From: Tom Lyon

    > there were a few icustomer nstallations. Bell Labs Indian Hill was one
    > - so that's why TSS was the base of their UNIX port.

"A UNIX System Implementation for System/370" (by W. A. Felton, G. L. Miller,
and J. M. Milner):

  https://www.bell-labs.com/usr/dmr/www/otherports/ibm.html

says "code to support System/370 I/O, paging, error recording and recovery,
and multiprocessing already existed in several available operating systems,
we investigated the possibility of using an existing operating system, or at
least the machine-interface parts of one, as a base to provide these
functions for the System/370 implementation ... Of the available systems,
TSS/370 came the closest to meeting our needs and was thus chosen as the base
for our UNIX system implementation". Alas, it doesn't say which other systems
were also considered.


    >> On May 6, 2022, at 09:39, arnold@skeeve.com wrote:

    >> So, why, given the letter from these folks, including DMR, did they go
    >> ahead and use the TSS solution anyway?

That paper says: "We initially thought about porting the UNIX operating
system directly to System/370 with minimal changes. Unfortunately, there are
a number of System/370 characteristics that, in the light of our objectives
and resources, made such a direct port unattractive. The Input/Output (I/O)
architecture of System/370 is rather complex; in a large configuration, the
operating system must deal with a bewildering number of channels,
controllers, and devices, many of which may be interconnected through
multiple paths. Recovery from hardware errors is both complex and
model-dependent. For hardware diagnosis and tracking, customer engineers
expect the operating system to provide error logs in a specific format;
software to support this logging and reporting would have to be written. ...
Finally, several models of System/370 machines provide multiprocessing, with
two (or more) processors operating with shared memory; the UNIX system did
not support multiprocessing."

Presumably these factors outweighed the factors listed in the
Haley/London/Maranzaro/Ritchie letter.

	Noel

             reply	other threads:[~2022-05-06 15:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06 15:33 Noel Chiappa [this message]
2022-05-07 19:03 ` arnold
  -- strict thread matches above, loose matches on Subject: below --
2022-05-05 21:32 Tom Lyon via TUHS
2022-05-05 23:01 ` Adam Thornton
2022-05-06 22:54   ` Kevin Bowling
2022-05-06  7:35 ` arnold
2022-05-06  8:08   ` Ron Natalie
2022-05-06 14:21     ` Tom Lyon via TUHS
2022-05-06 15:51       ` Tom Ivar Helbekkmo via TUHS

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220506153317.D499D18C07A@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).