Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <sfuld@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: interative use, The Design of Design
Date: Tue, 7 May 2024 23:50:04 -0700
Organization: A noiseless patient Spider
Lines: 83
Message-ID: <v1f7as$3d5bq$1@dont-email.me>
References: <v03uh5$gbd5$1@dont-email.me> <v1dq8i$3d52j$1@dont-email.me>
 <v1dr1l$3da0b$1@dont-email.me> <v1dud5$3e2c6$1@dont-email.me>
 <v1e0h2$15vm$1@gal.iecc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 08 May 2024 08:50:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a94c25946c95f02a4f0a94b290ee391c";
	logging-data="3577210"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180VbLN8xgUOGZ0n75bzmD4dDWN5qJ/AWE="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gXjJd9b0Rgf7OpbHhlsyF9xGuyk=
In-Reply-To: <v1e0h2$15vm$1@gal.iecc.com>
Content-Language: en-US
Bytes: 4604

On 5/7/2024 12:47 PM, John Levine wrote:
> According to Stephen Fuld <SFuld@alumni.cmu.edu.invalid>:
>> In what sense was the S/360 architecture, designed for terminal use?  I
>> already talked about the base register, BALR/Using stuff that prevented
>> an interative program from being swapped out and swapped in to a
>> different real memory location.  This was a significant hinderance to
>> "terminal use".
> 
> With sufficiently disciplined programming, you could swap and move data
> by updating the base registers.  APL\360 did this quite successfully
> and handled a lot of interactive users on a 360/50.

Wasn't APL\360 an interpreter?  If so, then moving instructions and data 
around was considerably simpler.



> Reading between the lines in the IBMSJ architecture paper, I get the
> impression they believed that moving code and data with base registers
> would be a lot easier than it was, and missed the facts that a lot of
> pointers are stored in memory, and it is hard to know what registers
> are being used as base registers when.

Interesting.  That would seem to imply that it wasn't that they didn't 
think about the problems that base addressing would cause, they just 
(vastly) underestimated the cost of fixing it.  A different "design" 
problem indeed.



> This paper from U of Michigan lays out the problem and proposes a
> paging design which soon became the 360/67:
> 
> https://dl.acm.org/doi/pdf/10.1145/321312.321313
> 
> TSS was a disaster due to an extreme case of second system syndrome,
> but Michigan's MTS and IBM skunkworks CP/67 worked great.
> 
>> BTW, another problem occurs in transaction workloads where there is
>> another level of software between the user and the OS, but insteaed of
>> TSO, it was IMS or CICS, ...
> 
> There's two ways to write interacticve software, which I call the time-sharing
> approach and the SAGE approach.  In the time-sharing approach, the operating system
> stops and starts user processes and transparently saves and restores the process
> status.  In the SAGE approach, programs are broken up into little pieces each of
> which runs straight through, explicitly saves whatever context it needs to, and
> then returns to the OS.

Unconventional terminology, but clear and I agree with your point.  It 
is perhaps ironic that TSO (Time Sharing Option)/360 did not use the
"time sharing" approach.  :-(



> The bad news about the SAGE approach is that the programming is
> tedious and as you note bugs can be catastrophic. The good news is
> that it can get fantastic performance for lots of users.

I think the key word here is "can".  TSO/360 was a performance dog.  :-(



> It was
> invented for the SAGE missile defense system on tube computers in the
> 1950s, adapted for the SABRE airline reservation system on 7094s in
> the 1960s and has been used over and over, with the current trendy
> version being node.js. We now have better ways to describe
> continuations which make the programming a little easier, but it's
> still a tradeoff. IMS and CICS used the SAGE approach to provide good
> performance on specific applications.

Agreed.  But the tradeoff with CICS (I don't know about IMS) was the 
extra overhead of two levels of scheduling.  I believe this is why it 
was not useful for the highest performance systems that instead used ACP.




-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)