I like this up to a point - I would prefer to have an execution command and 
then be able to do if/then/else and another step, etc.

Or just use standard TSO allocation and program call syntax, perhaps simplified 
to be more JCL 'like'

--------------------------------------------------------------------------
Lionel B. Dyck (Contractor)  <sdg><
Mainframe Systems Programmer – RavenTek Solution Partners



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Hobart Spitz
Sent: Monday, July 02, 2018 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] 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 <
0000000433f07816-dmarc-requ...@listserv.ua.edu> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to