John, Thanks for the response.
>>Large snip<< >> 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). My thought is to contain the changes to the Converter only, no changes to the Interpreter or any other components. This will restrict what new functions can be provided but I think it has the potential to provide some significant new capability as well as provide a good platform for other future changes. Your comment regarding "new Coke" goes to the heart of my concern. If the "new JCL" does not provide an overwhelming improvement such that people want to use it then it probably doesn't make any sense. So the question I am trying to explore is can there be enough new capability added to the Converter (only) to get over this threshold ? I think there is, but it all depends upon what the collective sense what the existing JCL deficiencies are. It probably doesn't need to be said but I will anyway, the introduction of the "new JCL" would need to exist side by side with the "old JCL". So unlike the introduction of "new Coke" wherein "Coke classic" suddenly became a precious commodity "old JCL" will live on :-) I know you are a Linux/Unix guy so I would describe this as a "fork" (or is it a spawn ?), I am not a Unix guy so I will defer to you on that :-) You just gotta tip your hat to an OS that allows you to say: "I need to kill the daemon spawn" with a straight face :-) >> Large snip << >I know a few "new" facilities I might like in JCL. Or maybe they are more l>ike "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. This sounds like a useful new function, however it would require changes "downstream" from the Converter (including CA-11 and other restart managers :-) thus I would say it is out of scope. >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=. I can sympathize with your desire, but I can hear the ocean starting to boil so I would say this needs to be brought forward separately. >// JCLLIB ORDER= - One guess - Correct! Allow me to specify a UNIX >directory for PROCs and members which are // INCLUDE . Again, lower case >and >8 characters would be nice. The use of z/OS UNIX directories could actually be contained as a Converter only change, and thus falls into what I believe is containable. Although I suspect that "lower case and >8 characters" may be a bridge to far :-( and would not make the cut. (Note: My guess (I have no specific knowledge) is that the Converter currently uses FIND or perhaps BLDL to locate PROCs/INCLUDEs, neither of which provide the needed support. There is a faint glimmer of hope for this. it would first require that DESERV be added to the list of services that support z/OS UNIX directories and then the Converter could take advantage of this support.) >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. Ok now you have officially fallen off the cliff and the ocean is definitely boiling :-), all of the above is (significantly) out of scope. >=== 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 >// 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. Interesting ideas, but I can envision several "downstream" impacts that significantly raise the complexity/cost well beyond the threshold I was hoping to maintain. I would say that these ideas need to be dealt with separately, perhaps "new Coke with a lime twist" :-) >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. >> Snip << >John McKown John, I judge you to be someone who can see both "classic" z/OS and "new" Linux/Unix capabilities and is always looking for opportunities to bring the "new" to the "classic". I think this is a useful and creative outlook so I thank you for contributions to this discussion. John McDowell ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
