*PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We
have had time to shake out the issues.
parm_value = ’this is a parameter string’
ADDRESS LINK ’TESTMODA’ parm_value
or
ADDRESS LINKPGM "PROGRAM p1 p2 ... pn"
We also have ways to provide SYSIN and capture SYSLST:
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
example (from book):
ARG file_name
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
idcams_input.0 = 1
idcams_input.1 = ’LISTCAT CLUSTER’
ADDRESS LINK ’IDCAMS MARGINS(1 80)’
IF rc = 0
THEN CALL Print_Only_Lines_Including file_name
ELSE SAY ’IDCAMS LISTCAT fails with RC=’rc
EXIT
Print_Only_Lines_Including:
ARG search_name
DO line = 1 to idcams_output.0
IF WORDPOS(search_name,translate(idcams_output.line))¬=0
THEN SAY idcams_output.line
END
RETURN
Tony Thigpen
Seymour J Metz wrote on 07/03/2018 10:32 AM:
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
