On Mon, 9 Jul 2018 08:46:56 -0400, Hobart Spitz wrote: > >I think that it's important to first understand the characteristics on >which many people base their thinking that JCL is good and may never go >away. The point is important, and the basis is a valid concern. The >conclusion is wrong. All it takes is understanding the problem and coming >up with creative solutions. As I describe below, DB2 based applications >and those that use only PDSEs are likely to be good starting points. > ISPF provides an alternative ENQ mechanism for both Classic PDS and PDSE, successfully assuming that EXC ENQs will be transitory. OTOH, LMPUT requires EXC ENQ, needlessly for PDSE members.
>One valuable feature of z/OS batch processing is that all ENQs for the >entire JOB are obtained before any step execution actually starts. This is >done to prevent a deadly embrace: JOB A has exclusive access to dataset X >and needs exclusive access to dataset Y. JOB B has access to Y and needs >exclusive on X. Neither JOB can proceed until one is canceled, resulting >in lost production. Despite this being a useful service, there is no TSO >equivalent, either via a parallel ENQs (as Seymour suggested) or a standard >SLEEP mechanism to allow for retries. > Unless there's a time limit or loop count limit, this results in similar deadlocks. >... >When a batch JOB becomes eligible for execution these actions, relevant to >our subject, happen in this order: > > 1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are > merged with the submitted JCL. These are necessary for #2 below. > 2. Substitutions are processed. This is needed for #3; if DSNs could > change later, via substitution or IF, the ENQs would be incorrect. > Data set aliases break this assumption. > 3. ENQs are obtained on all datasets. > But for ALIAS names, not RELATED names. > 4. The EXECs for PGMs are processed, in order, one at a time. > At this point an ENQ for the RELATED name is attempted. There is no recovery from ENQ failure. >So any REXX implementation would have either to forgo do initial ENQs, or >commit to not changing DSNs during processing, or observe certain >conventions. These conventions could include the following, one or the >other may be appropriate depending on the applications' needs: > > - Perform ENQs in a consistent order. (Left as an exercise for the > reader. :-) ) > However effective this is, I doubt that it's practical. I suspect you feel likewise. > - Do all ALLOCations up front, and free all exclusive allocations before > a second set of ENQs is requested. > "exclusive" doesn't suffice. Imagine that JOB A has shared access to dataset X and needs exclusive access to dataset Y. JOB B has shared access to Y and needs exclusive on X. Deadlock occurs. > - Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET > or ALLOC failure, and taking appropriate action to recover/restart/suspend > processing. Initial ENQs are not required. If implemented via a common > routine, either site or vendor provided, this could be more viable. A > little additional coding to support automated restart might be needed; ... > ??? SMOP? > - Something else. > ??? Another exercise for the reader? > ... > 3. The JCL syntax (which is based on that of assembler AFAIK, a highly > inappropriate choice) is obscure, unintuitive, irregular, ... > Many Assembler facilities were created diachronically with insufficient design consideration. Consider the difference in semantics between macro arguments and SETC arguments. > ... and has a steep learning curve. > ITYM "shallow" learning curve. Proficiency is acquired slowly. > 4. JCL is a barrier to attracting new business to z/OS. Bad news if you > are a vendor. > Yes. > 6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs > prevent this. z/OS must know all dataset names to do the ENQs. > 7. You can not loop or retry, as was done in the application I described > above. > 8. You can't compare strings, do arithmetic, or employ complex logic. > 9. You can't call a function or return a string value. > Should JCL assimilate HLASM's conditional assembly facility? > 10. String/SET/PROC value substitution can convoluted. Do I need a > double period and/or a double ampersand? If you are passing a value down > two PROC level, you may have to put in 4 (!) ampersands or quotes to > indicate 1. More than two levels? Good luck!! REXX has no such > requirement. > Much of this could be resolved by adding HLASM's DOUBLE BIF to JCL. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
