Andrew wrote:
>I actually like JCL. One of the things it does so well that no-one even
notices is allocation of resources.
Then you haven't fully considered the alternatives. That's not a
criticism, just a statement of fact. How many of us really know how our
computers, cars, phones, bodies or anything else we live with day to day,
really work, at least until they don't, then we start caring.
Here's an actual example: I was riding in the back of an Uber recently,
and I felt every single bump, as if the chassis was bottoming out. I asked
some casual questions of the driver about the car. She said she bought it
used and tires kept exploding when she hit a pothole. I'd never had
exploding tire, so I suggested that the cause might be that her shocks
weren't not doing the job they were intended for, i.e. mitigating
irregularities in the roadway. (Consider a pothole a large value of
irregularity.)
The point is, you can proceed for a long time without understanding what
your tools are doing for you, but the day may come when you (or someone
else) will need to have that knowledge.
>In a previous job I tried to write scripts on a unix system to try to fix
tasks that had a tendency to open one file and then wait for another, where
multiple tasks >were deadlocking.
It may take a little more skill and experience to write in a real scripting
language than in JCL, but it should be done. I submit that this attitude
contributes to the high cost of running z/OS. The many things that happen
in batch are hidden, and IMHO, contribute to greater "large system effect"
than with leaner operating systems such as z/VM, *nix and *nix
derivatives. IBM and its stockholders love it when your company has to
spend more on hardware, especially when that hardware is so cheap to make
that they can afford to ship you 16 processors, when your company only
orders and pays for 1.
>This is so simple with JCL because you don't get one allocation until you
get them all.
That's what my suggested host command/function would do. It would probably
have a behaviour that would allow it to be used only once, to prevent
deadlocks, unless all previous ENQs were freed. The second use, without
FREE, could cause a JOB cancelation, possibly unconditionally, so that
well-meaning misuse would be discouraged, or, alternatively, only if the
ENQs could not be satisfied.
>The connection between program (DDNAME) and resources (dataset etc.) is
nice too. In something like Rexx you need to pass the names as arguments
(JCL is >much better than one long command line) or hard code them.
That's only because z/OS is so JCL oriented. Again, this works in IBM (and
shareholders) favor. It's harder to leave for another platform.
Gil wrote:
>Have you a realistic alternative?
For starters, consider something that uses REXX syntax and JCL semantics:
1.
*/* REXX */ *
2.
*arg String /* From SUBMIT or start task command. */ *
3.
*"jcl myjob: job (acct),'john smith',class=t,msgclass=h,notify="userid()" *
4.
*"jcl exec pgm=myprog,parm="date("s") *
5.
*"jcl sysprint: dd sysout=*" *
6. *...*
The JCL host command could create the exact same control blocks and
structures as the existing JCL statements today. When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup. All exits would be preserved so
that third-party software would still work unchanged. The JCL EXEC host
command could generate code to set RC.stepname supporting condition code
testing, and the JCL DD host command could set stepname.ddname.DSN, etc.,
to allow for reference to all parameters. This approach would, however,
limit the benefits of batch REXX.
I'm sure there are lots of other ways to do it. Use more DB2 and PDSEs. A
combination of REXX and PIPElines means that temporary datasets, and their
2 (or more) can be replaced with just one single character.
>In one case, I was able to enumerate a superset of the
>DSNs I might want to allocate in a Rexx step. I added EXEC
PGM=IEFBR14,COND=(0,LE)
>with DD statements for those at the end of the job just to avoid ENQ
surprises.
>JCL automates the enumeration of the ENQs; DYNALLOC, a newcomer, doesn't
>play by the old rules.
I use this technique when all else fails, and recommend it with one
exception. Put that those DDs in the first step of the job. You can FREE
something you won't need in the rest of the JOB, in case another
JOB/process might need it, without risking a deadly embrace.
I do advocate a combined REXX and PIPElines environment as a replacement
for JCL; z/VM works swimmingly with it. Perhaps z/OS fossilized thinking
is why the best things in z/OS (DB2, REXX, PIPElines) came from z/VM. We'd
all be just as happy if *nix could offer the same productivity and
performance benefits. Doing things character by character is just as bad
and old as JCL. That needs to change.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Mon, Jul 2, 2018 at 9:56 AM, John McKown <john.archie.mck...@gmail.com>
wrote:
> On Sun, Jul 1, 2018 at 12:12 PM Hobart Spitz <orexx...@gmail.com> wrote:
>
> > )Why don't we just skip the JCL, and write our jobs in REXX? The two
> >
> > Here, here!! Actually, there is one thing that is critical to retiring
> > JCL. It's a host command that allows a REXX program to list and wait for
> > all it's datasets and their enqueues to be available. This is not
> trivial,
> > so that's why no installation has taken it on. I don't know why IBM
> keeps
> > shoe-horning new features with big astonishment factors into JCL. z/OS
> is
> > the only major platform with a separate batch-only language.
> >
> > Anyone want to write sn RFE?
> >
> >
> I very much agree that JCL needs to be retired. It has a long and
> not-so-lustrous career. However, at least for me, one major thing which
> needs to be a critical consideration is restarting a "batch process" (aka
> REXX program, shell script). There needs to be someway which will, like
> CA-11 for instance, track what DSNs / UNIX files were created so that they
> can be automatically deleted when it is necessary. The new process must
> have a monitor which will keep track of which "step" equivalent has
> executed and be able to do something like a CA-11 restart. This becomes
> very complicated if the new processor can do looping. I can envision a REXX
> like environment where you can something like:
>
> /* REXX batch process */
> ADDRESS BATCH /* activate the BATCH environment */
> DSNPATTERN='SOMEHLQ.PROCESS.**.INPUT'
> "FINDDSNS (DSNPATTERN) (STEM DSN."
> /* Above does a catalog search for the DSNs described in DSNPATTERN */
> /* DSN.0 == Number of DSNs found */
> /* DSN.? (1 to DSN.0) == DSN found */
> "ENQDSN (ISTEM DSN. OSTEM DDN. TIMEOUT 3600"
> /* Above does a SYSDSN enqueue on all DSNs in the stem, waiting up to 3600
> seconds -- 1 hour */
> /* ISTEM is a REXX "array" of DSNs which are input to the ENQDSN
> OSTEM is a parallel REXX "array" of DDNs which are allocated to
> the corresponding ISTEM input DSN.
> */
> IF RC <> 0 THEN DO; /* ENQ FAILED -- nothing allocated */
> SAY "ENQ TIMED OUT -- ABORTING"
> EXIT 16 /* END BATCH PROCESS WITH CC OF 16 */
> END
> DO DDN_NUM = 1 TO DDN.0
> "REALLOC SYSIN " DDN.DDN_NUM
> /* The above does a FREE on SYSIN (unless OPEN) and reallocates
> DDN.DDN_NUM
> to the DDN of SYSIN -- assumes DDN is harded coded in the program
> */
> ADDRESS ATTACH "SOMEPGM PARM TO SOMEPGM" /* standard BATCH parameter
> list */
> "CKPT" /* tell the BATCH environment to "checkpoint" somewhere */
> END
>
>
> The above is just some "off the cuff" thoughts and a simple example of how
> something _might_ look. The BATCH environment is the replacement for JCL.
> It somehow communicates either with the JES system record checkpoint
> information for "restarting" the batch process if something happens. I
> didn't go into this because I simply don't have any good ideas.
>
>
> --
> There is no such thing as the Cloud. It is just somebody else’s computer.
>
> Maranatha! <><
> John McKown
>
> ----------------------------------------------------------------------
> 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
