Re: The Design of Design

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.

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?

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,

 
No comment about JCL still being used today.

IBM takes backward compatibility really seriously.




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