Re: The Design of Design

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

Tim Rentsch wrote:
>
snip
>

Personally I think his assessment of JCL is harsher than it
deserves.  Don't get me wrong, JCL is not my idea of a great
control language, but it was usable enough in the environment
that customers were used to.

>
From 1972-1979 I worked at a site that had boh S/360s (mostly /65s)
running OS/MVT, and Univac 1108s running Exec 8.  I used both,
though did mostly 1108 stuff.
>
For several reasons, JCL was terrible.  One was its seemingly
needless obscurity.  For example, IIRC the program name of the COBOL
compiler was ICKFBL00.  In contrast, the COBOL compiler under Exec 8
was called COB.  It aalso lacked intelligent defaults, which made a
it more cumbersome to use.  But this was mostly hidden due to a much
bigger problem.
>
Perhaps due to the architectures inability to swap a program out and
reload it to any real address other than the one it had originally,
all resources to be used had to be avaable at the beginning of the
job, so all JCL was scanned at the beginning of the job, and no
"dynamic" allocations were possible.
>
So, for example, the COBOL compiler needed, besides the input file
name, IIRC four scratch files, an output file and a place to put the
(spooled)print listing.  These must be explicitly described (JCL DD
commands) in the JCL for the job, Similarly for other programs.
This was so inconvenient that IBM provided "Procedures" (essentially
JCL macros), that included all the necessry DD statements, hid the
actual program names, etc.)  Thus to compile link and execute a
COBOL program you invoked the procedure called something like
ICOBUCLG (I have forgotten exactly, but the last thre characters
were for Compile, Link, and GO).  Contrast that with the EXEC 8
command
>
 @COB programname
>
(The @ was Exec's equivalent to // to indicate a comand) The
internal scratch files were alocated internally by the compiler,
the default print output (which could be overridden) went to the
printer, the default output name (again overridable) was the same
as the input (object files and source files could have the same
name).
>
Similarly, to copy a file from one place to another, JCL required
at least two DD cards and an exec card with the program IEBGENER.
Under Exec 8, the command
>
@Copy sourcefile, destinationfile
>
was sufficient, as both files would be dynamically assigned (Exec
term) internally by the copy program, and the indicator of success
or failure went to the default print output.
>
While, as you stated, programmers dealt with this, and it worked
in batch mode.  But it clearly wouldn't work once time sharing
(called Demand in Exec terminology) became available.  Thus IBM
had to invent a whole new, incompatible set of commands for TSO.
But the Exec 8 syntax was so straightforward that users used
exactly the same commands, keyed in at the terminal as were put on
cards or a file in batch mode.  That difference persists to this
day.

I have no problem accepting all of your characterizations as
accurate.  Like I said, I'm not a fan of JCL, not at all, I just
think it wasn't as bad as the commentary in The Design of Design
makes it out to be.

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.

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.

It isn't clear that trying
to do something more ambitious would have fared any better in the
early 1960s (see also The Second System Effect in MMM).

>
Exec 8 was roughly comtemporaeous with OS/MVT.  I claim, was a
much better choice,

Let me clarify my earlier statement:  It isn't clear that >>IBM<<
trying to do something more ambitious would have fared any better
(at least not at that time).  The people who did Exec 8 didn't have
the baggage of IBM's customer model (here again I am speculating),
so it was easier for them to do a better job.