Re: The Design of Design

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

Tim Rentsch wrote:
>

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

>
snip
>
>

The biggest fault of JCL is that it
is trying to solve the wrong problem.

>
What problem was it trying to solve and what was the "right"
problem?

>
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

I'm having trouble making sense of this question.  Did you mean
there was no interactive model?  Certainly there was a
non-interactive model, which is in the batch approach to the
world.

when JCL was devised.

OS/360 was announced in April 1964, at the same time as System/360.
Surely there had been significant thought put into what JCL would
look like by that time, which puts it in the early 1960s.

They didn't address it because they couldn't forcast
(obviouslyincorrectly), that it would be a problem to solve.

Talking about System/360 and OS/360 in The Design of Design, Brooks
distinguishes between teleprocessing and interactive use, aka
time-sharing.  Teleprocessing is for remote submission of batch jobs
and for fixed applications such as airline reservation systems.  He
doesn't say why time-sharing was given short shrift but there is
this interesting statement:  "There was no conscious decision to
cater to two use modes [namely, batch and interactive];  it merely
reflected subgroups holding differing use models."  It seems clear
that the design team, including Brooks himself, expected that the
primary use mode would be batch-like (which includes teleprocessing
applications such as airline reservation systems).

The problem that was in need of addressing is interactive use.  I
think there are two reasons why JCL was so poor at that.  One is
that they knew that teleprocessing would be important, but they
tried to cram it into the batch processing model, rather than
understanding a more interactive work style.  The second reason is
that the culture at IBM, at least at that time, never understood the
idea that using computers can be (and should be) easy and fun.  The
B in IBM is Business, and Business isn't supposed to be fun.  And I
think that's part of why JCL was not viewed (at IBM) as a failure,
because their Business customers didn't mind.  Needless to say, I am
speculating, but for what it's worth those are my speculations.

>
Fair enough.  A couple of comments.  By the time TSO/360 came out,in
IIRC the early 1970s, they were already committed to JCL.  TSO ran as a
batch job on top of the OS, and handled swapping, etc.itself within the
region allocated to TSO within the OS.  It was a disaster.  Of course
this was later addressed by unifying TSO into the OS, but that couldn't
happen until the S/370s (except the 155 and 165) and virtual memory.
But the legacy of two control languages was already set by then.

To me this sounds like another manifestation of the business
mindset.  IBM didn't understand interactive computing because
business users, their primary market, spend their time "working" and
not "goofing off".  Interactive use was seen as catering to people
who aren't serious about getting work done.  Here again I am of
course speculating, although the speculations are consistent with
what I remember from that time.

By the way I used TSO and also supported CICS for a while in the
1970s.  So my speculations have at least some foundation in real
experience.

As for "fun".  I agree that IBM didn't think of computers as fun, but
there were plenty of reasons to support interactive terminals for
purely business reasons, a major one being programmer productivity in
developing business applications.

I don't disagree.  I conjecture that there was an unconscious
attitude at IBM at that time that interfered with them giving
interactive use serious consideration.  Furthermore it isn't obvious
that they made a bad decision, considering the environment of the
marketplace of the time.  Real interactive use was just not very
important for IBM's primary market at that time, and investing
effort in supporting interactive computing might very well have
cost them sales in their primary market.  After all, IBM was in
business to make money;  they weren't in business to advance the
state of the art in new computing technologies.