On Wed, 4 Jul 2018 11:21:27 -0500, Joel C. Ewing wrote: >On 07/04/2018 02:53 AM, Ward Able, Grant wrote: >> I seldom post here, but have been intrigued by this thread. >> >> What are the problems (perceived or real) that will be resolved by replacing >> JCL with REXX? >> JCL has numerous restrictions and inconsistencies due to antiquity, resource constraints, and developer indolence. Programmers find Rexx free of many of these and naively say, "Replace JCL with Rexx!" Well, Rexx is there. Use it for what you prefer, if it works.
JCL's design had a few principal objectives: o Support for 029 keypunch and 2540 card reader. Nowadays this is more an impediment than a boon. o Preserving data set integrity while precluding deadlocks. This depends on static identification, frustrating the frequent wish, "I want to name a data set dynamically, embedding the execution date.time." o Other (specify?) Otherwise, there are numerous improvements that could be made, mainly in the Reader (Converter?) phase. My growing list: o Relax the 71-character limitation. o Make continuation convention friendlier. o Allow symbol names to span continuations. o Allow SET between first and second catenands of a data set concatenation. o Support reader phase looping/branching. o Fix referbacks/overrides for nested PROC calls. o Make JCL symbol substitution notionally consistent between JCL statements and instream data sets. o Provide analogue of HLASM DOUBLE BIF. o Allow substitution wherever a symbol occurs, not only in a handful of contexts. o Remove VOL=REF requirement for temp DSN referbacks. o Enforce label agreement among IF/THEN/ELSE/ENDIF. o (But strive for compatibility with existing JCLLIB/PROCLIBs.) >I don't think anyone who has dealt with production batch failure >recovery and restart would seriously consider just replacing JCL with >REXX. What is really needed is a new job stream descriptive language >that would address the failings of JCL. Perhaps with enough add-on >functions in REXX, REXX could initially be used to implement job streams >described in that new descriptive language. Just using native REXX to >do what current JCL does for a single job step would be much more >verbose and hence more tedious and error prone. Also writing REXX code >that has multiple distinct steps can become very complex if you must >also design it to support restarts in the middle when the inevitable >failure occurs that prevents all steps from executing correctly. > >The main issues that a JCL replacement would need to address that >current JCL does not are >(1) the gosh-awful syntax of JCL, a hodgepodge of parameters, >sub-parameters, keyword-value parameters, positional-value parameters, >positional-keyword parameters, with non-obvious inter-relations between >parameters and column sensitivity, not to mention conditional statements >vs conditional parameters on EXEC statements > >(2)the very limited ways that the execution sequence of job steps can be >influenced by the results of prior job steps -- essentially the only >control directly supported by JCL is a numeric return code, and that is >not even available if the step aborts. It would be nice if symbolic >values and dynamic data set names could be passed back to the job stream >from a job step for use by later job steps. There is no way in JCL to >define a loop structure or a repeat of job steps. Think how cool it >would be if the job descriptor language could actually specify how to >diagnose some standard job step failures and automatically run steps >known to fix the problem, and then rerun the failed step. > >(3)JCL PROCs are not flexible enough to be used like procedures in a >procedural language. It would be nice to have support for a construct >that could behave much closer to the concept of a procedure. At least >in the past, restrictions on the total number of job steps in a job, >including those generated by PROCs, were limits that frequently >constrained the design of complex production job streams. > >(4)Enough status information about the execution process of the job >stream would have to be preserved to enable determination of >success/failure of the job stream and to determine how and where to >restart in the event of failure. > >(5)It would be nice to have greater control over handling disposition of >job step data sets than the current ABEND/not-ABEND distinction. It >would be nice to have simpler control over the types step failures that >should produce a DUMP. > >(6)And all these features would have to be done without breaking the >very useful features of current JCL, like handling the concurrent >enqueues on data sets and device assignment to avoid integrity exposures >and improper sequence of usage by competing job streams. > >These are the main things about MVS JCL I have found repeatedly annoying >over the decades, but the solution is not trivial or someone would >produced an alternative by now. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
