From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25345 invoked from network); 6 May 2022 15:39:29 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 6 May 2022 15:39:29 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 01EE69D036; Sat, 7 May 2022 01:39:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 1C7149CEEF; Sat, 7 May 2022 01:37:01 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8C15E9CEEF; Sat, 7 May 2022 01:33:19 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id E8B439CEEE for ; Sat, 7 May 2022 01:33:18 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D499D18C07A; Fri, 6 May 2022 11:33:17 -0400 (EDT) To: tuhs@minnie.tuhs.org Message-Id: <20220506153317.D499D18C07A@mercury.lcs.mit.edu> Date: Fri, 6 May 2022 11:33:17 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979) X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: jnc@mercury.lcs.mit.edu Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > 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