Maybe this response will start some kind of religious war, but:
today I'm working with z/OS most of the time, but in my former life I was a
VM/CMS person. And I enjoyed the way of doing batch there very much,
that is:
you write a REXX exec, where you do the necessary file assignments using
FILEDEF (which is much the same as a DD statement) and then you call the
load module simply by entering its name (if there is no EXEC with this
name,
REXX looks for a MODULE with the given name). Of course, you could specify
some kind of special ADDRESS XXX command first.
So we have the same language there for CMS dialog and batch; you simply
disconnect
from your CMS machine, and the execution continues as a batch machine.
To modify your FILEDEF statements (for example, computing file names
etc.), you
have the full power of the REXX language.
I would like it very much to do my batch job planning using REXX instead
of JCL syntax.
With TSO and REXX, for example, we are able to compute data set names
using REXX
at run time ... I would like to have true scripting facilities in batch
processing, too.
In fact, this is all possible today, if you start a batch TSO session
and REXX, and
then - for example - your COBOL or PL/1 programs under the control of this
environment, but it is normally not done for production work. And I
believe, it is not
done, because there is no control what happens by looking at the JCL any
more ...
So I think the limitations of JCL which are bad for us (developers) make
other
people happy.
If there are no "political" obstacles:
what would be needed? The batch initiators need to be combined with a REXX
interpreter, and some kind of command (similar to FILEDEF) should
replace the DD statements ...
ok, this is maybe far too simple minded, but it could be possible, IMHO.
Like in VM/CMS,
you would have to issue the FILEDEF commands prior to the execution of
the module;
don't know, if there should be a FILEDEF * (CLEAR, too. Is this
automatically done at
the end of the job step? Do we still have a job step? Can we control the
begin and end
of a job step? Does the execution of the REXX survive the termination of
the job step?
Of course, it should ... these are some of the questions to be answered
if we go deeper
into the details ...
Kind regards
Bernd
Am 09.11.2013 19:07, schrieb John McDowell:
When I think about JCL I always view it in the context of a means by which a
person can describe what they want the (z/OS) system to do. To my way of
thinking this is analogous to the many programming languages (e.g. COBOL, PL/I,
JAVA, etc.) which are used by a person to describe what they want the
(hardware) system to do. And just as the many programming languages
demonstrate there are lots of ways a person can convey what they want, some of
which are more complex than others :-)
With this context in mind I would be interested in hearing ideas about what JCL could be. Let's not try to
"boil the ocean" :-) but rather limit ourselves to changing the human interface (e.g. JCL) and not
require changes to the underlying (z/OS) system. (Note: To my way of thinking this guideline is the most
important and also the most difficult to follow. It is important because the "cost" (e.g.
complexity, etc.) gets higher and higher the wider the scope of change. And it is difficult to follow
because it is not always obvious what system components are affected by changes to "JCL".)
In broad terms I would offer the following:
- Changing the basic nature of a "job" from a static entity to a dynamic one falls into
the "boiling the ocean" category :-)
- Modifying the maximum allowable value of an attribute (e.g. dataset name length, the
number of steps, etc.) is likely to be in the "boiling the ocean" category
- Creating a new attribute (that needs to be acted on by a component other than
the Converter/Interpreter (C/I)) is difficult
- Providing new functions that are performed by the C/I (e.g. iteration,
simple arithmetic, etc.) is possible
- Changing how an attribute gets assigned a value (e.g. a dataset name, a
ddname, etc.) is easy
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
