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? > > > > Regards – Grant. > > In theory, there's no difference between theory and practice. In practice, > there is. > > There is no such thing as the Cloud. It is just somebody else’s computer. > > If you don't have time to do it right, when will you have the time to do it > over? - John Wooden > > > DTCC Internal (Green) > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Paul Gilmartin > Sent: 03 July 2018 21:39 > To: [email protected] > Subject: Re: REXX as JCL replacement > > ATTENTION! This email originated outside of DTCC; exercise caution. > > > On Tue, 3 Jul 2018 15:39:40 -0400, Tony Thigpen wrote: > >> PARSE SOURCE on VSE returns: >> VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC TESTREXX VSE >> VSE ? >> > So it would be practical to multipath for compatibility. > >> VSE does not have pipelines. >> > z/OS barely has Pipelines. An obsolete version. And hard to order. > > For more than you want to know about Rexx (in)compatibility, see Dave Alcocks > http://planetmvs.com/rexxanywhere/index.html > > OK. Thanks. Comparing z/VSE and Z/OS ADDRESS environments, I see: > > z/VSE z/OS > > Ref. SC33-6642-10 SA32-0972-30 > > LINK Like JCL EXEC or Assembler Call I think this is a relic of > CMS calling > with only one argument. conventions. I've never > used it. > > LINKPGM Like Assembler CALL with multiple Like Assembler CALL; length > halfwords not > arguments; length halfwords generated generated automatically. > automatically. > > LINKMVS n/a Like Assembler CALL with > multiple > arguments; length halfwords > generated > automatically. (This seems > to be > z/VSE's LINKPGM.) > > -- gil > ...
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. Joel C. Ewing -- Joel C. Ewing, Bentonville, AR [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
