Hello John,
I would like to clarify my viewpoint:
first, I believe that traditional JCL must stay and needs to be improved
in the way that the other posters suggested.
What I would like to see is a second way of doing batch on z/OS, where
we have a sort of command line interface, like TSO ALLOC, FREE and
ISPF SELECT PGM, for example, but without the burden of starting
TSO, REXX and ISPF first - and with the power of REXX to manipulate
the batch commands.
We need some sort of clever replacements for
- DD statements
- EXEC statements
- STEPLIB concatenations
which can be used from this new command line interface (in batch !)
without much limitation compared to the existing JCL interface, if
possible,
but with the possibility to add REXX as a control language (or other
scripting languages, BTW).
I don't want this to replace traditional JCL, but to add a second line of
batch processing. Maybe some shops do more and more work with this
technique,
maybe others stay with (old) JCL.
Restart problems have to be solved; if the new batches contain loops
etc, the
restart information has to contain information about the status of the
controlling
REXX. There is no general solution to that, and there will be batches
that are
not restartable (same situation as today, I believe).
Could we maybe make the mainframe platform more attractive this way to
younger people? I could imagine that JCL is one of the reasons why they
don't like the mainframe now. At least that's what I often hear when doing
classes with 20 year old students on PL/1 and similar topics ... they like
the language, but they dislike the environment and especially JCL ...
BTW: I don't really think that this will happen, but if we're talking about
dreams, that's what I'd really like to see. There are some efforts to make
the platform attractive (RDZ etc.), but that's too expensive IMO, and it
leaves the platform unchanged and only hides the old things from the
novice users, instead of really improving the platform itself.
Kind regards
Bernd
Am 10.11.2013 03:48, schrieb John McDowell:
Bernd,
I believe REXX has great potential to help in the "new JCL".
But before we go any further in this discussion I need to caution that trying to bring
the CMS "batch" model you describe is much more akin to using REXX in (batch)
TSO (e.g. PGM=IKJEFT01 or IKJEFT1A or IKJEFT1B). As such it falls prey to the problem
that John McKown describes in his reply in this thread. Additionally it has other
deficiencies that make it unacceptable, on the other hand the good news is that this
capability already exists (as described above) if you want to use it :-)
The nature of JCL (today) is a two part process, as can be seen in the name(s) Converter/Interpreter (C/I).
In simplistic terms the Converter "compiles" the JCL card images into "internal text"
which the Interpreter than evaluates. Thus there is already a clear delineation between the external
representation (e.g. JOB, EXEC, DD statements, etc.) and the internal representation that is actually used by
the system. By the way, in response to John McKnown's fears I will say take heart :-) You can rest assured
that CA-11 does not look at "JCL" but rather it looks at (and modifies) the various control block
structures (e.g. SCT, etc.) that the system constructs.
This delineation is what Paul Gilmartin referred to in his response in the other thread on this topic (Subject: JCL) as "converter
time" vs. "execution time". Strictly speaking "execution time" is not completely accurate but it is close enough
for our purposes :-) I would propose that most (all ?) of the complaints regarding JCL can be solved by changes at "converter
time". Certainly I believe that the list Paul enumerates can either be dealt with at "converter time" or are outside the
scope of "JCL" altogether.
I believe that using REXX (largely) as a substitute for the JCL statements we
know today has great potential, both from a technical implementation point of
view as well as from a usability point of view. The technical and usability
requirements are sometimes in conflict but in this instance I think there is a
happy congruence :-) There are several reasons that make using REXX for this
purpose attractive, in my opinion and if the idea of using REXX holds up to
scrutiny I'll be happy to describe them.
But before we go to far along this path I would be interested in hearing
dissenting opinions or even in hearing more ideas about people would like to
see (or not see :-) in JCL.
John McDowell
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
