On Sat, Nov 9, 2013 at 8:48 PM, John McDowell <jmcd...@gmail.com> wrote:
> 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. > I was aware of that. I just being sort of "high level". My manager used to work for UCELL and CA and worked on the internals of CA-11. So I got a bit too much information, like the dog that sniffed the third rail <grin/>. The problem is that I don't see a way to creatly enhance JCL, perhaps with REXX inspired features, without ripping up those internal control blocks. But does JCL really need "loopling"? Yes, I can envision changing things where DSNs are generated and processed in a loop. But I really don't know how to _extend_ JCL to do this as opposed to a complete replacement. So that a person could use the legacy JCL facility, or convert to the "new JCL" (which will likely go over as well as "new Coke" did). > > 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. > I know a few "new" facilities I might like in JCL. Or maybe they are more like "enhancements". Take DISP. Please. There are three subparameters. The first is NEW, OLD, or MOD. The second is the normal execution disposition (KEEP, CATLG, DELETE, UNCATLG). The third is the conditional disposition. I could use something like DISP=MOD but which ups up a SHARE enqueue instead of an EXCLUSIVE enqueue. This would be for "log" files in jobs which I want to look at in SDSF as the job runs. No, I don't want the damn stuff on SPOOL. How about DISP=REP? That would delete and uncatalog the DSN if it already exists, then create it like DISP=NEW. Yes, CA-11 takes care of this for me. I'd like JCL support, please. Conditional disposition - I could see a real nice feature if I could say something like "use 3rd disposition if the RC of step is > (or < or = or >=, ...) good-value" instead of requiring an ABEND. STEPLIB - I'm weird ( a well known fact). I'd like to be able to put a UNIX directory path in a STEPLIB or JOBLIB. This instead of using PDS/E libraries. Yes, I like z/OS UNIX file systems. Sue me (please don't). It would even be nice to be able to refer to lower case program names > 8 characters in the PGM=. // JCLLIB ORDER= - One guess - Correct! Allow me to specify a UNIX subdirectory for PROCs and members which are // INCLUDE . Again, lower case and >8 characters would be nice. Specification of members of a PDS by "wild card". I would sometimes be useful to me to process all members, or selected members, of a PDS in member name order. This change might be a JCL change or a BPAM change, but I might want to have a DD like: //MEMBERS DD DISP=SHR,DSN=SYS1.PARMLIB(BPXPRM*) And what the program which opens the MEMBERS DD gets is the contents of the BPXPRM* members in member name order. OK, let's be complete and allow UNIX files too: //MEMBERS DD PATH='/some/dire/BUBBA*',FILEDATA=TEXT, and so on for UNIX parameters. === really difficult === parallel job steps. JCL runs each STEP in the order it exists in the JCL, perhaps bypassing some steps based on return codes. How about // PARALLEL //COMPILE1 EXEC PROC=COMPILE,PGM=PGM1 //COMPILE2 EXEC PROC=COMPILE,PGM=PGM2 //COMPILE3 EXEC PROC=COMPILE,PGM=PGM3 // ENDPARALLEL Is this really necessary? No. I know some program who might drool over it. On my tiny z9BC, not much use. For a shop running a full blown zEC12 with 80 CPs? Talk about nice. Another possible use is to combine this // PARALLEL with z/OS UNIX named pipes (DSNTYPE=FIFO). Where one step feeds data to a parallel step over the FIFO. Today, if something like this is needed, we usually see use of &&DSN type temporaries. An example: The compile and link procedures. Instead of the compiler writing SYSLIN to a &&DSN and the BINDER read from that &&DSN, use // PARALLEL to run the compiler and BINDER, linking them with a FIFO. This would be very excellent if the PATH value could be some sort of "temporary" FIFO created by the system like &&DSN is a temporary disk data set. It's late and I'm not really well (speaking physically, not mentally!). Are any of these new features critical? Well, not right now. But if some of them become available, they might become critical as cleaver people find uses for them. > > John McDowell > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
