Re: interative use, The Design of Design

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)