Re: The Design of Design

Thomas Koenig wrote:

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> schrieb:

Scott Lurndal wrote:
 

"Stephen Fuld" <SFuld@alumni.cmu.edu.invalid> writes:

Tim Rentsch wrote:

 

The problem it was trying to solve is contained in its name:

Job >> >> Control Language.  It tacitly accepted the non-interactive
batch >> >> model for what it needed to address.

 
You may be right, but correct me if I am wrong, there was no
non-interactive model in the mid 1960s when JCL was devised.

 
BASIC and DTSS was developed in 1963.

 
 
Good Point.  So IBM was "guuilty" of vastly mis-understanding and
under estimating the future importance of interactive users.

 
Only the team that made JCL, it seems.

Just as an aside, though this thread may be somewhat OT, I consider it
fun and interesting.

I am not sure exactly what he is saying here.  By JCL, does he mean
just the syntax of the language, the funky program names, etc., or doea
he include the things like the requirement that all allocation be done
before the first program executes, which is perhaps more of an OS
design issue?

 
Brooks claims that System/360 was premeditated for terminal
use from the start, and that somebody didn't get the memo
when designing JCL (my words).

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 lcation.  This was a significant hinderance to
"terminal use".

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, which did the terminal handling and imposed
another level of scheduling (i.e. IMS/CICS competed with other programs
for OS resources and the transactions within IMS/CICS competed with
each other for the resources that IMS/CICS got.)  Note that this
overhead was so much that the high volume transaction users couldn't
use it and instead developed their own OS (ACP).

Also, the protection mechanism of S/360 was such that there was no
protection between transactions within CICS (Idon'tknow about IMS),
such that an errant subscript could cause the overwriting of other
transactions, or even CICS itself.   This was also fixed with the
S/370s virtual memory.





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