When you reinvent the wheel, please make them round. A procedural replacement for JCL has all sorts of issues, regardless of syntax. Instead, why not
1. Enhance Dynalloc to have a parallel allocation function. 2. Enhance IRXJCL to allow a script in a sequential dataset. 3. Enhance REXX to support parallel allocation. The installation could then provide custom procedures for invoking IRXJCL -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Hobart Spitz <[email protected]> Sent: Monday, July 2, 2018 2:37 PM To: [email protected] Subject: Re: REXX as JCL replacement How about something like this? Use REXX syntax and a JCL host command with JCL-like semantics: /* REXX */ arg String /* From SUBMIT or start task command. */ "jcl job myjob: (acct),'john smith',class=t,msgclass=h,notify="userid() "jcl exec pgm=myprog,parm="date("s") "jcl sysprint: dd sysout=*" "jcl sysin dd *" "jcl data" String ... The JCL host command could create the exact same control blocks as the existing JCL statements today, but not begin execution. When the REXX exec exited, ENQs would be processed as now, followed by the current processing, including step execution, and cleanup. All exit/interfaces would be preserved so that third-party software would still work unchanged. OREXXMan JCL is the buggy whip of 21st century computing. Stabilize it. Put Pipelines in the z/OS base. Would you rather process data one character at a time (Unix/C style), or one record at a time? IBM has been looking for an HLL for program products; REXX is that language. On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin < [email protected]> wrote: > On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: > > >Oh my gosh, you would have to maintain JCL forever for that and a dozen > other reasons. > > > >BUT! Conceivably ... conceivably ... you might stabilize it and do > everything new in Rexx going forward. > > > If the replacement had a superset of JCL function, providing a > JCL-to-replacement > translation utility would allow discarding direct support for JCL. > > >-----Original Message----- > >From: John Melcher, Jr > >Sent: Monday, July 2, 2018 10:46 AM > > > >Once upon a time a LONG time ago this was a GUIDE requirement. It was > >voted down due to the amount of automated systems that generated JCL. > >You'd have to keep JCL, probably forever, because of those systems. > > -- gil > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
