[TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Tom Lyon via TUHS]

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

I was (re?)introduced to Chuck Haley recently and discovered he had a copy
of a Bell Labs memo from himself, London, Maranzaro, and Ritchie.  They
suggest that the path pursued to get UNIX running in/under TSS/370 was the
hard way to go.

Enjoy:
http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf


-- 
- Tom

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

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Adam Thornton]

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



> On May 5, 2022, at 2:32 PM, Tom Lyon via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
> I was (re?)introduced to Chuck Haley recently and discovered he had a copy of a Bell Labs memo from himself, London, Maranzaro, and Ritchie.  They suggest that the path pursued to get UNIX running in/under TSS/370 was the hard way to go.
> 
> Enjoy:  http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf <http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf>
Oh my.

I mean, I know that OS (and descendants--for those of you without this particular trauma, we mostly mean MVS (now z/OS), but of course there's OS/MFT, OS/MVT, and then OS/MVS)  was always trying to kill VM, and we went through similar crap with Linux/390 (and zLinux), which contains code to let it run directly on the iron, even though even production shops are not going to *do* that (OpenSolaris-for-z required VM underneath it; hell, it required a couple new DIAGs we requested).

That actually makes it easy to run zLinux on Hercules, so I'm not complaining, but...it's not how any shop running it as anything other than a curiosity would do it.  I mean, OK, I guess you could have a teeny little LPAR but let's face it the LPAR is basically VM.

But TSS was always *also* an also-ran (that is, not OS).  It's really weird (to me, anyway) to see it was hostile to VM too.

Adam

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

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Kevin Bowling]

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

On Thu, May 5, 2022 at 4:03 PM Adam Thornton <athornton@gmail.com> wrote:

>
>
> On May 5, 2022, at 2:32 PM, Tom Lyon via TUHS <tuhs@minnie.tuhs.org>
> wrote:
>
> I was (re?)introduced to Chuck Haley recently and discovered he had a copy
> of a Bell Labs memo from himself, London, Maranzaro, and Ritchie.  They
> suggest that the path pursued to get UNIX running in/under TSS/370 was the
> hard way to go.
>
> Enjoy:
> http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf
>
>
> Oh my.
>
> I mean, I know that OS (and descendants--for those of you without this
> particular trauma, we mostly mean MVS (now z/OS), but of course there's
> OS/MFT, OS/MVT, and then OS/MVS)  was always trying to kill VM, and we went
> through similar crap with Linux/390 (and zLinux), which contains code to
> let it run directly on the iron, even though even production shops are not
> going to *do* that (OpenSolaris-for-z required VM underneath it; hell, it
> required a couple new DIAGs we requested).
>
> That actually makes it easy to run zLinux on Hercules, so I'm not
> complaining, but...it's not how any shop running it as anything other than
> a curiosity would do it.  I mean, OK, I guess you could have a teeny little
> LPAR but let's face it the LPAR is basically VM.
>

Possibly metaphorically but this LPAR facility is provided by PR/SM
starting with later 3090s and ES/9000.  There is good coverage in IBM
Systems Journal or IBM R&D journal (I can check my archives for which one
if anyone needs a reference). It’s a firmware hypervisor like pHyp or Sun’s
ldom.  VM is a strange yet delightful strain of operating system where full
virtualization was front and center for both time sharing and isolation.
There’s really nothing quite like it although lately things like Qubes and
MirageOS may share some of the delights.

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

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[arnold]

Tom Lyon via TUHS <tuhs@minnie.tuhs.org> wrote:

> I was (re?)introduced to Chuck Haley recently and discovered he had a copy
> of a Bell Labs memo from himself, London, Maranzaro, and Ritchie.  They
> suggest that the path pursued to get UNIX running in/under TSS/370 was the
> hard way to go.
>
> Enjoy:
> http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf
>
>
> -- 
> - Tom

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

Just wondering.

Arnold

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Ron Natalie]

They liked kicking a dead whale down the beach.  

> On May 6, 2022, at 09:39, arnold@skeeve.com wrote:
> 
> Tom Lyon via TUHS <tuhs@minnie.tuhs.org> wrote:
> 
>> I was (re?)introduced to Chuck Haley recently and discovered he had a copy
>> of a Bell Labs memo from himself, London, Maranzaro, and Ritchie.  They
>> suggest that the path pursued to get UNIX running in/under TSS/370 was the
>> hard way to go.
>> 
>> Enjoy:
>> http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf
>> 
>> 
>> -- 
>> - Tom
> 
> So, why, given the letter from these folks, including DMR, did they go
> ahead and use the TSS solution anyway?
> 
> Just wondering.
> 
> Arnold

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Tom Lyon via TUHS]

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

Let's not mix whales and turkeys.

TSS was IBM's attempted answer to Multics - built specifically for
time-sharing, way too complex, and suffering from second-system syndrome.
It never reached product status, but there were a few icustomer
nstallations. Bell Labs Indian Hill was one - so that's why TSS was the
base of their UNIX port.
https://en.wikipedia.org/wiki/TSS_(operating_system)

TSO was the Time-Sharing Option - by far the most common time-sharing
environment for IBM, since it was an add-on to their mainstream OS family -
MFT, MVT, MVS, etc.  I had the joy(?) of using TSO for my 3 summers with
the El Paso Natural Gas company.  TSO is the system that earned the 'dead
whale down a beach' line from Steve Johnson; it was truly awful.  I'm sure
there was some TSO somewhere in BTL as well.
https://en.wikipedia.org/wiki/Time_Sharing_Option

The most sane time-sharing choice, and also the best for OS development,
was VM/CMS.  But for most of its life, IBM was trying to kill VM in favor
of the others.  AFAIK, there was no VM installation in BTL.  See Melinda
Varian's wonderful history of VM.
http://www.leeandmelindavarian.com/Melinda/neuvm.pdf

On Fri, May 6, 2022 at 1:08 AM Ron Natalie <ron@ronnatalie.com> wrote:

> They liked kicking a dead whale down the beach.
>
> > On May 6, 2022, at 09:39, arnold@skeeve.com wrote:
> >
> > Tom Lyon via TUHS <tuhs@minnie.tuhs.org> wrote:
> >
> >> I was (re?)introduced to Chuck Haley recently and discovered he had a
> copy
> >> of a Bell Labs memo from himself, London, Maranzaro, and Ritchie.  They
> >> suggest that the path pursued to get UNIX running in/under TSS/370 was
> the
> >> hard way to go.
> >>
> >> Enjoy:
> >>
> http://charles.the-haleys.org/papers/Alternate_Implementation_Proposal_for_Unix370.pdf
> >>
> >>
> >> --
> >> - Tom
> >
> > So, why, given the letter from these folks, including DMR, did they go
> > ahead and use the TSS solution anyway?
> >
> > Just wondering.
> >
> > Arnold
>
>

-- 
- Tom

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

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Tom Ivar Helbekkmo via TUHS]

Tom Lyon via TUHS <tuhs@minnie.tuhs.org> writes:

> The most sane time-sharing choice, and also the best for OS
> development, was VM/CMS.

CP SMSG RSCS CMD IEEE MSG PUGS Scripting stuff with REXX was fun, too!

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[Noel Chiappa]

    > 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

Re: [TUHS] Alternative Implementation Proposal for Unix/370 (BTL, 1979)

[arnold]

Thanks Noel.

Those reasons are quite compelling. One gets the sense that they wanted
to get UNIX going on the 370 as quickly as posible.

jnc@mercury.lcs.mit.edu (Noel Chiappa) wrote:

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