Discussion:
REXX as JCL replacement
(too old to reply)
John Melcher, Jr
2018-07-02 17:46:20 UTC
Permalink
Raw Message
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.
--
This message (and reply) was read by Google and the NSA.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-02 18:10:40 UTC
Permalink
Raw Message
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.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John Melcher, Jr
Sent: Monday, July 2, 2018 10:46 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: REXX as JCL replacement

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.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-02 18:26:48 UTC
Permalink
Raw Message
Post by Charles Mills
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.
Post by Charles Mills
-----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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-02 18:37:36 UTC
Permalink
Raw Message
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 <
Post by Charles Mills
Post by Charles Mills
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
Post by Charles Mills
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.
Post by Charles Mills
-----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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dyck, Lionel B. , RavenTek
2018-07-02 18:41:29 UTC
Permalink
Raw Message
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-***@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz
Sent: Monday, July 02, 2018 1:37 PM
To: IBM-***@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 <
Post by Charles Mills
Post by Charles Mills
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
Post by Charles Mills
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.
Post by Charles Mills
-----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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-03 14:32:53 UTC
Permalink
Raw Message
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 <IBM-***@listserv.ua.edu> on behalf of Hobart Spitz <***@GMAIL.COM>
Sent: Monday, July 2, 2018 2:37 PM
To: IBM-***@listserv.ua.edu
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 <
Post by Charles Mills
Post by Charles Mills
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
Post by Charles Mills
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.
Post by Charles Mills
-----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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-03 14:50:34 UTC
Permalink
Raw Message
And all of those are relatively simple "atomic" changes with few if any
negatives, and "goodness" that transcends JCL replacement.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Tuesday, July 3, 2018 7:33 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-03 14:58:36 UTC
Permalink
Raw Message
*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
Post by Seymour J Metz
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
________________________________________
Sent: Monday, July 2, 2018 2:37 PM
Subject: Re: REXX as JCL replacement
How about something like this?
/* 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 <
Post by Charles Mills
Post by Charles Mills
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
Post by Charles Mills
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.
Post by Charles Mills
-----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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-03 16:24:20 UTC
Permalink
Raw Message
*PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We have had time to shake out the issues.
Yes, but would it be feasible to port these to z/OS? Something like
the enhancements to DYNALLOC that Shmuel discusses. It can't be done
entirely by enhancements to the Rexx interpreter.

Does z/VSE perform multiple allocations with no deadlock hazard?
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
For generality, these should have a DDNAME operand; an
enhancement such as:

call outtrap "sysprint_stem. (dd sysprint"
call outtrap "sysut2_stem. (dd sysut2"

call rexxipt "sysin_stem. (dd sysin"
call rexxipt "sysut1_stem. (dd sysut1"
(I certainly recommend quoting symbol names to prevent evaluation.)

address LINKMVS "IEBGENER"
(Neither LINK nor LINKPGM provides a z/OS compatible plist.)

Would Pipelines provide an alternative to (enhanced) OUTTRAP
and REXXIPT? I've asked a similar question on CMS-PIPELINES
but always been misunderstood. The answers told me of stages
to connect to the other end of the DDNAME.
Post by Seymour J Metz
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
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-03 17:26:03 UTC
Permalink
Raw Message
This probably doesn't need to be said, but all(/most?) Access Method
Services (IDCAMS) commands are TSO commands.

Under TSO, it's enough to write:
...
call outtrap "CmdOut."
"listcat cluster"
call outtrap "off"
...

or

...
"pipe listcat | stem CmdOut."
...

In PIPElines, LISTCAT is a built-in stage. I am not sure about using
cluster here.



On Tue, 3 Jul 2018, 12:24 pm Paul Gilmartin, <
Post by Tony Thigpen
Post by Tony Thigpen
*PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We
have had time to shake out the issues.
Yes, but would it be feasible to port these to z/OS? Something like
the enhancements to DYNALLOC that Shmuel discusses. It can't be done
entirely by enhancements to the Rexx interpreter.
Does z/VSE perform multiple allocations with no deadlock hazard?
Post by Tony Thigpen
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
For generality, these should have a DDNAME operand; an
call outtrap "sysprint_stem. (dd sysprint"
call outtrap "sysut2_stem. (dd sysut2"
call rexxipt "sysin_stem. (dd sysin"
call rexxipt "sysut1_stem. (dd sysut1"
(I certainly recommend quoting symbol names to prevent evaluation.)
address LINKMVS "IEBGENER"
(Neither LINK nor LINKPGM provides a z/OS compatible plist.)
Would Pipelines provide an alternative to (enhanced) OUTTRAP
and REXXIPT? I've asked a similar question on CMS-PIPELINES
but always been misunderstood. The answers told me of stages
to connect to the other end of the DDNAME.
Post by Tony Thigpen
Post by Seymour J Metz
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
Post by Tony Thigpen
Post by Seymour J Metz
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
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-03 17:39:59 UTC
Permalink
Raw Message
While I know that it will not be possible to port the code, I mainly am
concerned with source level close-compatibility.

For example, LINK or LINKPGM can be different under the covers to
support a z/OS parm list. (I am not sure that there is a difference, but
am taking your word on it.)

And, adding extra options to something is always allowable. But, I would
default rexxipt to use a DD of SYSIN and outtrap to use a DD of SYSPRINT.

Tony Thigpen
Post by Paul Gilmartin
*PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We have had time to shake out the issues.
Yes, but would it be feasible to port these to z/OS? Something like
the enhancements to DYNALLOC that Shmuel discusses. It can't be done
entirely by enhancements to the Rexx interpreter.
Does z/VSE perform multiple allocations with no deadlock hazard?
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
For generality, these should have a DDNAME operand; an
call outtrap "sysprint_stem. (dd sysprint"
call outtrap "sysut2_stem. (dd sysut2"
call rexxipt "sysin_stem. (dd sysin"
call rexxipt "sysut1_stem. (dd sysut1"
(I certainly recommend quoting symbol names to prevent evaluation.)
address LINKMVS "IEBGENER"
(Neither LINK nor LINKPGM provides a z/OS compatible plist.)
Would Pipelines provide an alternative to (enhanced) OUTTRAP
and REXXIPT? I've asked a similar question on CMS-PIPELINES
but always been misunderstood. The answers told me of stages
to connect to the other end of the DDNAME.
Post by Seymour J Metz
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
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-07-02 18:41:58 UTC
Permalink
Raw Message
There appears to be a visceral urge in some to force others to conform to
their great vision of the new and better way (ergo DST). That isn't at all
necessary in this case (nor DST). Just do it. Yourself. Now, or whenever
you have the time.

The simultaneous enqueue issue seems to be the biggest technical issue. I
see these possible solutions:
a) Use JCL...
b) Write a utility that will do it.
c) Avoid the need for it.

JCL is not ever going away, and to interact with the system as it exists,
some JCL is going to be needed. A JOB card, an EXEC PGM=IRXJCL (a somewhat
ironic name), and //SYSEXEC DD. But that would be a generic template,
depending on what you need to do with JOB card parameters.

Start small... you don't have to build Rome in one day, or boil the ocean.

sas

On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin <
Post by Charles Mills
Post by Charles Mills
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
Post by Charles Mills
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.
Post by Charles Mills
-----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,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
CM Poncelet
2018-07-02 20:58:09 UTC
Permalink
Raw Message
D'accord - and the next 'complaint' will be about that pesky machine
code and how to get rid of it. Those who find JCL challenging argue that
it is not needed. As Aesop's fox said, "the grape is sour." My ha'penny. CP
Post by Steve Smith
There appears to be a visceral urge in some to force others to conform to
their great vision of the new and better way (ergo DST). That isn't at all
necessary in this case (nor DST). Just do it. Yourself. Now, or whenever
you have the time.
The simultaneous enqueue issue seems to be the biggest technical issue. I
a) Use JCL...
b) Write a utility that will do it.
c) Avoid the need for it.
JCL is not ever going away, and to interact with the system as it exists,
some JCL is going to be needed. A JOB card, an EXEC PGM=IRXJCL (a somewhat
ironic name), and //SYSEXEC DD. But that would be a generic template,
depending on what you need to do with JOB card parameters.
Start small... you don't have to build Rome in one day, or boil the ocean.
sas
On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin <
Post by Charles Mills
Post by Charles Mills
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
Post by Charles Mills
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.
Post by Charles Mills
-----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,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-02 21:24:01 UTC
Permalink
Raw Message
Post by Steve Smith
There appears to be a visceral urge in some to force others to conform to
their great vision of the new and better way (ergo DST). That isn't at all
necessary ... Just do it. Yourself.
Force? Not in that case. Set your wrist watch to whatever offset you choose.
Publish the hours of operation of your business in whatever timezone, Standard,
Daylight, UTC, whatever.

But things work better if people agree.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-03 19:17:48 UTC
Permalink
Raw Message
Post by Hobart Spitz
This probably doesn't need to be said, but all(/most?) Access Method
Services (IDCAMS) commands are TSO commands.
...
call outtrap "CmdOut."
"listcat cluster"
call outtrap "off"
...
or
...
"pipe listcat | stem CmdOut."
...
In PIPElines, LISTCAT is a built-in stage. I am not sure about using
cluster here.
This thread concerns replacing JCL, not replacing or enhancing TSO. There are
many utilities available via JCL which are not TSO commands nor Pipelines
stages. I've used SMP/E extensively. I do not expect and scarcely want to see
SMP/E refactored as a TSO command or a Pipelines stage.
Post by Hobart Spitz
While I know that it will not be possible to port the code, I mainly am
concerned with source level close-compatibility.
For example, LINK or LINKPGM can be different under the covers to
support a z/OS parm list. (I am not sure that there is a difference, but
am taking your word on it.)
Ouch! Conway's Law. Grrr...

LINK, LINKPGM, and LINKMVS are all different. LINKMVS provides the interface
closest to Assembler Call or JCL EXEC. It is widely used. z/OS LINKPGM provides
a different interface. It's less widely used, but there are examples in SYS1.SAMPLIB.
The closest compatibility would be achieved by adding LINKMVS (LINKOS would be
a better name) to z/VSE Rexx, even if it is simply an alias for z/VSE LINKPGM. This
would leave a compatibility issue for the few programs that use z/OS LINKPGM.
The problem hasn't arisen; it's unlikely.

What does PARSE SOURCE report on z/VSE? Might a programmer case this out
and issue ADDRESS VALUE 'LINKPGM' on VSE and ADDRESS VALUE 'LINKMVS'
on z/OS?
Post by Hobart Spitz
And, adding extra options to something is always allowable. But, I would
default rexxipt to use a DD of SYSIN and outtrap to use a DD of SYSPRINT.
Mostly good. Except when Rexx is executed with IRXJCL, OUTTRAP effectively
traps DD SYSTSPRT.

Ouch! Conway's Law. Grrr...

We haven't discussed APF authorization under the hypothetical JCL replacement.

Is Pipelines available under z/VSE?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-03 19:39:50 UTC
Permalink
Raw Message
PARSE SOURCE on VSE returns:
VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC
TESTREXX VSE VSE ?

VSE does not have pipelines.

Tony Thigpen
Post by Paul Gilmartin
Post by Hobart Spitz
This probably doesn't need to be said, but all(/most?) Access Method
Services (IDCAMS) commands are TSO commands.
...
call outtrap "CmdOut."
"listcat cluster"
call outtrap "off"
...
or
...
"pipe listcat | stem CmdOut."
...
In PIPElines, LISTCAT is a built-in stage. I am not sure about using
cluster here.
This thread concerns replacing JCL, not replacing or enhancing TSO. There are
many utilities available via JCL which are not TSO commands nor Pipelines
stages. I've used SMP/E extensively. I do not expect and scarcely want to see
SMP/E refactored as a TSO command or a Pipelines stage.
Post by Hobart Spitz
While I know that it will not be possible to port the code, I mainly am
concerned with source level close-compatibility.
For example, LINK or LINKPGM can be different under the covers to
support a z/OS parm list. (I am not sure that there is a difference, but
am taking your word on it.)
Ouch! Conway's Law. Grrr...
LINK, LINKPGM, and LINKMVS are all different. LINKMVS provides the interface
closest to Assembler Call or JCL EXEC. It is widely used. z/OS LINKPGM provides
a different interface. It's less widely used, but there are examples in SYS1.SAMPLIB.
The closest compatibility would be achieved by adding LINKMVS (LINKOS would be
a better name) to z/VSE Rexx, even if it is simply an alias for z/VSE LINKPGM. This
would leave a compatibility issue for the few programs that use z/OS LINKPGM.
The problem hasn't arisen; it's unlikely.
What does PARSE SOURCE report on z/VSE? Might a programmer case this out
and issue ADDRESS VALUE 'LINKPGM' on VSE and ADDRESS VALUE 'LINKMVS'
on z/OS?
Post by Hobart Spitz
And, adding extra options to something is always allowable. But, I would
default rexxipt to use a DD of SYSIN and outtrap to use a DD of SYSPRINT.
Mostly good. Except when Rexx is executed with IRXJCL, OUTTRAP effectively
traps DD SYSTSPRT.
Ouch! Conway's Law. Grrr...
We haven't discussed APF authorization under the hypothetical JCL replacement.
Is Pipelines available under z/VSE?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-03 20:38:46 UTC
Permalink
Raw Message
Post by Tony Thigpen
VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC
TESTREXX VSE VSE ?
So it would be practical to multipath for compatibility.
Post by Tony Thigpen
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ward Able, Grant
2018-07-04 07:53:46 UTC
Permalink
Raw Message
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:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

ATTENTION! This email originated outside of DTCC; exercise caution.
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-09 12:47:08 UTC
Permalink
Raw Message
Post by Ward Able, Grant
What are the problems (perceived or real) that will be resolved by replacing JCL with REXX?
I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away. The point is important, and the basis is a valid concern. The
conclusion is wrong. All it takes is understanding the problem and coming
up with creative solutions. As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts. This is
done to prevent a deadly embrace: JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y. JOB B has access to Y and needs
exclusive on X. Neither JOB can proceed until one is canceled, resulting
in lost production. Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't. I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities. I'll share my best
educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to
our subject, happen in this order:

1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
3. ENQs are obtained on all datasets.
4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions. These conventions could include the following, one or the
other may be appropriate depending on the applications' needs:

- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; see
also below on my first attempt at using REXX instead of JCL.
- Something else.

It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s. As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern. E.g. an application where
all data updates are done to DB2 tables and PDSEs. Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere. Some smart developer may come to understand this and
provide the missing service. Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis. Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers. At the same time that existing customers are locked
in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems. This would most
likely apply DB2 base applications, where all the DDs are for DB2 libraries
reference with DISP=SHR.

Give it a try. If you get down to just a fraction your previous
conventional JOBs, your management might get the idea that you are
onto something and change any fossilized mind-set about JCL.

If all your DISP='s are SHR, you may already have the opportunity to
streamline your application. This is not theory. I have done it, as I
describe in the next paragraph. AFAIK, you can code SHR for PDSEs in the
common cases. REWRITE/UPDATE in place is the main exception; you at least
get an abend in testing, unlike the scenario if you update-in-place a PDS
with DISP=SHR, and you just lose data.

(Apologies to anyone who has seen/heard this before. I'll abbreviate.) In
the early 1990s, I was working on a DB2 application that had hundreds of
JOB streams, most differing by 1 or more of 3 parameter values, phase,
client, and bill cycle. JOBs were submitted manually based on a visual
check of a DB2 table that tracked the current state of processing for each
batch process. Programs checked that same table to be sure that the
processing requested had passed the previous phase. All updates were to
DB2 tables. I determined that we could eliminate most of the JOBs and
automate processing with REXX and a DB2/REXX interface. We ended up with
less than 10 job streams, each of which would check for ready work, execute
the COBOL program for that work, and then loop back and look for more
work. Since the different phase processes could be executed in parallel
for different billing cycles and/or clients, one phase might complete
its work, making new work ready for the next phase via loopback check,
while the previous phase was being processed. Driving work from this phase
tracking table meant that we had automatic restart. If a process failed,
any needed corrective action would be taken, and the JCL resubmitted,
unchanged(!). Sometimes no resubmission was necessary if that phase was
already working. No RESTARTs to code, no PARMs to update, no dataset names
to override, and not third-party software.

This summarizes my thoughts on the JCL problems that REXX would address,
per Ward's request:

1. JCL creates an unnecessary, manditory, artificial, arbitrary, and
counter-productive distinction between scripting code and application
code. This the most important problem with JCL, and the hardest for single
platform staff and management to understand and accept. Under REXX, the
distinction entirely optional.
2. The communication between scripting (JCL) and application code is
limited. One (or some) strings in, and 4 digits (0-4095) out. TSO
supports return codes up to 16M, and REXX has no limit other than that
imposed by the invocation interface. The PARM= value can't come from a
file, DB2 table, or run-time expression. With REXX, these and other
options are available.
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, and has a steep
learning curve. That should be no surprise to anyone who has been paying
attention to the frequent questions about JCL on IBM-MAIN, and other
boards, that almost always get one of two answers: You can't do that, or
you have to do something weird and unintuitive. Using REXX, the syntax is
consistent, intuitive, powerful, and easy to use. The same expression
syntax is used everywhere.
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
5. JCL is a barrier to customers leaving z/OS, even for other IBM
platforms. Mixed news if you are a vendor.
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
11. Many of these limitations are addressed by complex work-arounds, or
expensive third-party packages that force you to work in a way dictated by
the software and not by your business requirements.

There may be other reasons.

Basically, JCL is so far from real a programming language, that I can't
describe it.

z/VM, like almost all other platforms, gets along swimmingly without a
separate batch language. You can issue CMS/zLinux/guest commands, or
invoke REXX programs to drive any batch process.

Replace your JCL with REXX a little at a time. Start with the low hanging
fruit and/or those that have automation requirements that are not addressed
in existing software. Focus on those that use DB2 table and PDSEs to store
data updates, and those JOBs that only have DISP=SHR. Replace updated PDSs
and sequential datasets with PDSEs, even if you only have one member. To
be really careful, make the changes so that you only have DISP-SHR in your
JCL. Once your are satisfied with that, replace the JCL with REXX. You
may have to experiment a bit. Post your questions if you are stuck.

JOB and any JESx control cards will mostly have to stay, and you will need
a TSO batch step. I recommend a PROC like this.

*//TSO PROC CMD=PROFILE*
*// EXEC PGM=IKJEFT01,PARM='&CMD'*
*//SYSPROC DD DISP=SHR,DSN=your site sysproc libs// DD
...//SYSEXEC DD DISP=SHR,DSN=your site sysexec libs// DD
...//SYSTSPRT DD SYSOUT=**
*//SYSPRINT DD SYSOUT=* Not required, but commonly used.*
*//* Additional commands can be added via SYSTSIN*
*//SYSTSIN DD DDNAME=SYSIN In case you forget SYSTSIN DD *.*
*// PEND*

It can be invoked thusly:

*//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
*// JCLLIB ORDER=(MY.JCL.LIB) Optional*
*// EXEC TSO*
*//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN use.*
*st*

*%myrexpgmalloc reuse dd(sysin) dummy*
*alloc reuse dd(sysut1) shr dsn(in.data)*
*alloc reuse dd(sysut2) mod dsn(out.data(results)) cyl space(10 10)
dsntype(library)*
*call *(iebgener)*
*//*

In general, all ALLOCs should include REUSE, since you maybe combining
multiple steps together or other programs might use the same DD. It
doesn't hurt.

Other handy things to add as you need them:

- A REXX exec to allocate DB2 libraries if you need them. Accept an arg
string that identifies the environment if you need to, or interrogate some
external source of information.
- A REXX exec to invoke batch ISPF. Allocate all your ISP*LIBs and
ISPTABL. Take an arg string in the form of CMD(...), PGM(...) PARM(...),
or PANEL(...), and append it to ISPSTART. Only non-display panels are
valid in batch. Include a loop (DO 10 UNTIL RC <> 995; "ISPSTART"
arg(1); END) in case ISPSTART fails with a 995(?) on an ISPTABL enqueue
failure. You must VPUT ZISPFRC to get the return code passed up to the
caller (IKJEFT01).
- A REXX function to convert a relative GDG reference to an absolute
one. This will let you ALLOC a GDG member.
- An ALLOC wrapper function (in REXX) to check SYSDSN(), and determine
if the disposition should be NEW CATALOG or SHR, so you don't have to use
the finicky MOD. Then proceed with the "ALLOC REUSE DDNAME(...) ..." , and
return the RC of ALLOC. I would use ARG DDNAME DISP DSNAME OPTIONS to
receive blank delimited values. Separate concatenated DSNs with abutted
commas. A DISP value of "ASIS" could request the condition NEW/SHR
disposition. Loop over all the args the same way. If any allocation
fails, free them all.

This is your chance to join the 21st century.

I hope this helps.

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.
Post by Ward Able, Grant
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-----
Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-09 15:09:46 UTC
Permalink
Raw Message
1. I don't recall anybody on IBM-MAIN claims that JCL is good.

2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.

2. Sleep does not address the deadly embrace problem.

3. PDSE does not solve the problem.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Hobart Spitz <***@GMAIL.COM>
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Post by Ward Able, Grant
What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away. The point is important, and the basis is a valid concern. The
conclusion is wrong. All it takes is understanding the problem and coming
up with creative solutions. As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts. This is
done to prevent a deadly embrace: JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y. JOB B has access to Y and needs
exclusive on X. Neither JOB can proceed until one is canceled, resulting
in lost production. Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't. I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities. I'll share my best
educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to
our subject, happen in this order:

1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
3. ENQs are obtained on all datasets.
4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions. These conventions could include the following, one or the
other may be appropriate depending on the applications' needs:

- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; see
also below on my first attempt at using REXX instead of JCL.
- Something else.

It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s. As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern. E.g. an application where
all data updates are done to DB2 tables and PDSEs. Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere. Some smart developer may come to understand this and
provide the missing service. Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis. Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers. At the same time that existing customers are locked
in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems. This would most
likely apply DB2 base applications, where all the DDs are for DB2 libraries
reference with DISP=SHR.

Give it a try. If you get down to just a fraction your previous
conventional JOBs, your management might get the idea that you are
onto something and change any fossilized mind-set about JCL.

If all your DISP='s are SHR, you may already have the opportunity to
streamline your application. This is not theory. I have done it, as I
describe in the next paragraph. AFAIK, you can code SHR for PDSEs in the
common cases. REWRITE/UPDATE in place is the main exception; you at least
get an abend in testing, unlike the scenario if you update-in-place a PDS
with DISP=SHR, and you just lose data.

(Apologies to anyone who has seen/heard this before. I'll abbreviate.) In
the early 1990s, I was working on a DB2 application that had hundreds of
JOB streams, most differing by 1 or more of 3 parameter values, phase,
client, and bill cycle. JOBs were submitted manually based on a visual
check of a DB2 table that tracked the current state of processing for each
batch process. Programs checked that same table to be sure that the
processing requested had passed the previous phase. All updates were to
DB2 tables. I determined that we could eliminate most of the JOBs and
automate processing with REXX and a DB2/REXX interface. We ended up with
less than 10 job streams, each of which would check for ready work, execute
the COBOL program for that work, and then loop back and look for more
work. Since the different phase processes could be executed in parallel
for different billing cycles and/or clients, one phase might complete
its work, making new work ready for the next phase via loopback check,
while the previous phase was being processed. Driving work from this phase
tracking table meant that we had automatic restart. If a process failed,
any needed corrective action would be taken, and the JCL resubmitted,
unchanged(!). Sometimes no resubmission was necessary if that phase was
already working. No RESTARTs to code, no PARMs to update, no dataset names
to override, and not third-party software.

This summarizes my thoughts on the JCL problems that REXX would address,
per Ward's request:

1. JCL creates an unnecessary, manditory, artificial, arbitrary, and
counter-productive distinction between scripting code and application
code. This the most important problem with JCL, and the hardest for single
platform staff and management to understand and accept. Under REXX, the
distinction entirely optional.
2. The communication between scripting (JCL) and application code is
limited. One (or some) strings in, and 4 digits (0-4095) out. TSO
supports return codes up to 16M, and REXX has no limit other than that
imposed by the invocation interface. The PARM= value can't come from a
file, DB2 table, or run-time expression. With REXX, these and other
options are available.
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, and has a steep
learning curve. That should be no surprise to anyone who has been paying
attention to the frequent questions about JCL on IBM-MAIN, and other
boards, that almost always get one of two answers: You can't do that, or
you have to do something weird and unintuitive. Using REXX, the syntax is
consistent, intuitive, powerful, and easy to use. The same expression
syntax is used everywhere.
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
5. JCL is a barrier to customers leaving z/OS, even for other IBM
platforms. Mixed news if you are a vendor.
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
11. Many of these limitations are addressed by complex work-arounds, or
expensive third-party packages that force you to work in a way dictated by
the software and not by your business requirements.

There may be other reasons.

Basically, JCL is so far from real a programming language, that I can't
describe it.

z/VM, like almost all other platforms, gets along swimmingly without a
separate batch language. You can issue CMS/zLinux/guest commands, or
invoke REXX programs to drive any batch process.

Replace your JCL with REXX a little at a time. Start with the low hanging
fruit and/or those that have automation requirements that are not addressed
in existing software. Focus on those that use DB2 table and PDSEs to store
data updates, and those JOBs that only have DISP=SHR. Replace updated PDSs
and sequential datasets with PDSEs, even if you only have one member. To
be really careful, make the changes so that you only have DISP-SHR in your
JCL. Once your are satisfied with that, replace the JCL with REXX. You
may have to experiment a bit. Post your questions if you are stuck.

JOB and any JESx control cards will mostly have to stay, and you will need
a TSO batch step. I recommend a PROC like this.

*//TSO PROC CMD=PROFILE*
*// EXEC PGM=IKJEFT01,PARM='&CMD'*
*//SYSPROC DD DISP=SHR,DSN=your site sysproc libs// DD
...//SYSEXEC DD DISP=SHR,DSN=your site sysexec libs// DD
...//SYSTSPRT DD SYSOUT=**
*//SYSPRINT DD SYSOUT=* Not required, but commonly used.*
*//* Additional commands can be added via SYSTSIN*
*//SYSTSIN DD DDNAME=SYSIN In case you forget SYSTSIN DD *.*
*// PEND*

It can be invoked thusly:

*//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
*// JCLLIB ORDER=(MY.JCL.LIB) Optional*
*// EXEC TSO*
*//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN use.*
*st*

*%myrexpgmalloc reuse dd(sysin) dummy*
*alloc reuse dd(sysut1) shr dsn(in.data)*
*alloc reuse dd(sysut2) mod dsn(out.data(results)) cyl space(10 10)
dsntype(library)*
*call *(iebgener)*
*//*

In general, all ALLOCs should include REUSE, since you maybe combining
multiple steps together or other programs might use the same DD. It
doesn't hurt.

Other handy things to add as you need them:

- A REXX exec to allocate DB2 libraries if you need them. Accept an arg
string that identifies the environment if you need to, or interrogate some
external source of information.
- A REXX exec to invoke batch ISPF. Allocate all your ISP*LIBs and
ISPTABL. Take an arg string in the form of CMD(...), PGM(...) PARM(...),
or PANEL(...), and append it to ISPSTART. Only non-display panels are
valid in batch. Include a loop (DO 10 UNTIL RC <> 995; "ISPSTART"
arg(1); END) in case ISPSTART fails with a 995(?) on an ISPTABL enqueue
failure. You must VPUT ZISPFRC to get the return code passed up to the
caller (IKJEFT01).
- A REXX function to convert a relative GDG reference to an absolute
one. This will let you ALLOC a GDG member.
- An ALLOC wrapper function (in REXX) to check SYSDSN(), and determine
if the disposition should be NEW CATALOG or SHR, so you don't have to use
the finicky MOD. Then proceed with the "ALLOC REUSE DDNAME(...) ..." , and
return the RC of ALLOC. I would use ARG DDNAME DISP DSNAME OPTIONS to
receive blank delimited values. Separate concatenated DSNs with abutted
commas. A DISP value of "ASIS" could request the condition NEW/SHR
disposition. Loop over all the args the same way. If any allocation
fails, free them all.

This is your chance to join the 21st century.

I hope this helps.

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.
Post by Ward Able, Grant
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-----
Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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://secure-web.cisco.com/1vQAahM_WEN0g-O0uf0FC49Sm1iZY1q5tU650TAzJAPfZA-6GgzWqmQIrZAGlNK4DGVa_0OXF96LD1tkYz5MlkqTvdRNoNdhc5yjZrD9qmi5h2ES78_bh08QhJNj9Tl8l6G5N2knmK6tZyBQ92hb-9vbFH0ehhFhpkXR9Tb00r2kuqUBUccdsMO2mnO2J3Psii1nswtaVb15FR7bbny20JeLJVyl3oO_T8ex9BQsdGjZHjJU4FVZTWv_IAaTX5ghLP_FLAX1tyrEbLJ0BmKLSi7_bJ5UESdd6omyotG4JSVGJpY7p--wbWa5JxyzSYgWpDcc9BjeSUVmx2POrXjBn-w6KLORmh5651iFW8d6mfHyJZ9pvQ4gbB25w1DoQ06brrgi3Vu2fG8CU-7Pd-6uVQIZ7q-7f3Q0y1FjOJDEd6abDRR_2QU3p-_TbFGVw4a96/http%3A%2F%2Fplanetmvs.com%2Frexxanywhere%2Findex.html
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-09 16:11:48 UTC
Permalink
Raw Message
Post by Seymour J Metz
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
There were such statements as "I like JCL", or similar.
Post by Seymour J Metz
2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.
I don't think anything I said was either.
Post by Seymour J Metz
2. Sleep does not address the deadly embrace problem.
I didn't claim that. It is needed to do your up front ENQs in REXX. You
still might have to exit with an error COND CODE if you can't get the ENQ
you need. A single ALLOC does not give the TSU a message or time to free
up the dataset.
Post by Seymour J Metz
3. PDSE does not solve the problem.
You'll have to explain that. From my reading of the doc., you can have
multiple readers and writers, in the same step or different JOBs opening
different members at the same time, provided the same member is not open
for OUTPUT by two different DCBs or JOBs/TSUs. All this with SHaRed
access, i.e. no DISP=OLD or equivalent. Note that I said, perhaps not
clearly enough, that the entire application, all foreground and background
accesses, must be SHaRed. What am I missing?

Thanks.
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Monday, July 9, 2018 8:46 AM
Subject: Re: REXX as JCL replacement
Post by Ward Able, Grant
What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?
I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away. The point is important, and the basis is a valid concern. The
conclusion is wrong. All it takes is understanding the problem and coming
up with creative solutions. As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.
One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts. This is
done to prevent a deadly embrace: JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y. JOB B has access to Y and needs
exclusive on X. Neither JOB can proceed until one is canceled, resulting
in lost production. Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.
Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't. I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities. I'll share my best
educated guesses with respect to the subject at hand.
When a batch JOB becomes eligible for execution these actions, relevant to
1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
3. ENQs are obtained on all datasets.
4. The EXECs for PGMs are processed, in order, one at a time.
So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions. These conventions could include the following, one or the
- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to
recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; see
also below on my first attempt at using REXX instead of JCL.
- Something else.
It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s. As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern. E.g. an application where
all data updates are done to DB2 tables and PDSEs. Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.
If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.
Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere. Some smart developer may come to understand this and
provide the missing service. Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis. Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers. At the same time that existing customers are locked
in, new customers are locked out for the same reasons.
I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.
That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems. This would most
likely apply DB2 base applications, where all the DDs are for DB2 libraries
reference with DISP=SHR.
Give it a try. If you get down to just a fraction your previous
conventional JOBs, your management might get the idea that you are
onto something and change any fossilized mind-set about JCL.
If all your DISP='s are SHR, you may already have the opportunity to
streamline your application. This is not theory. I have done it, as I
describe in the next paragraph. AFAIK, you can code SHR for PDSEs in the
common cases. REWRITE/UPDATE in place is the main exception; you at least
get an abend in testing, unlike the scenario if you update-in-place a PDS
with DISP=SHR, and you just lose data.
(Apologies to anyone who has seen/heard this before. I'll abbreviate.) In
the early 1990s, I was working on a DB2 application that had hundreds of
JOB streams, most differing by 1 or more of 3 parameter values, phase,
client, and bill cycle. JOBs were submitted manually based on a visual
check of a DB2 table that tracked the current state of processing for each
batch process. Programs checked that same table to be sure that the
processing requested had passed the previous phase. All updates were to
DB2 tables. I determined that we could eliminate most of the JOBs and
automate processing with REXX and a DB2/REXX interface. We ended up with
less than 10 job streams, each of which would check for ready work, execute
the COBOL program for that work, and then loop back and look for more
work. Since the different phase processes could be executed in parallel
for different billing cycles and/or clients, one phase might complete
its work, making new work ready for the next phase via loopback check,
while the previous phase was being processed. Driving work from this phase
tracking table meant that we had automatic restart. If a process failed,
any needed corrective action would be taken, and the JCL resubmitted,
unchanged(!). Sometimes no resubmission was necessary if that phase was
already working. No RESTARTs to code, no PARMs to update, no dataset names
to override, and not third-party software.
This summarizes my thoughts on the JCL problems that REXX would address,
1. JCL creates an unnecessary, manditory, artificial, arbitrary, and
counter-productive distinction between scripting code and application
code. This the most important problem with JCL, and the hardest for single
platform staff and management to understand and accept. Under REXX, the
distinction entirely optional.
2. The communication between scripting (JCL) and application code is
limited. One (or some) strings in, and 4 digits (0-4095) out. TSO
supports return codes up to 16M, and REXX has no limit other than that
imposed by the invocation interface. The PARM= value can't come from a
file, DB2 table, or run-time expression. With REXX, these and other
options are available.
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, and has a steep
learning curve. That should be no surprise to anyone who has been paying
attention to the frequent questions about JCL on IBM-MAIN, and other
boards, that almost always get one of two answers: You can't do that, or
you have to do something weird and unintuitive. Using REXX, the syntax is
consistent, intuitive, powerful, and easy to use. The same expression
syntax is used everywhere.
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
5. JCL is a barrier to customers leaving z/OS, even for other IBM
platforms. Mixed news if you are a vendor.
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
11. Many of these limitations are addressed by complex work-arounds, or
expensive third-party packages that force you to work in a way dictated by
the software and not by your business requirements.
There may be other reasons.
Basically, JCL is so far from real a programming language, that I can't
describe it.
z/VM, like almost all other platforms, gets along swimmingly without a
separate batch language. You can issue CMS/zLinux/guest commands, or
invoke REXX programs to drive any batch process.
Replace your JCL with REXX a little at a time. Start with the low hanging
fruit and/or those that have automation requirements that are not addressed
in existing software. Focus on those that use DB2 table and PDSEs to store
data updates, and those JOBs that only have DISP=SHR. Replace updated PDSs
and sequential datasets with PDSEs, even if you only have one member. To
be really careful, make the changes so that you only have DISP-SHR in your
JCL. Once your are satisfied with that, replace the JCL with REXX. You
may have to experiment a bit. Post your questions if you are stuck.
JOB and any JESx control cards will mostly have to stay, and you will need
a TSO batch step. I recommend a PROC like this.
*//TSO PROC CMD=PROFILE*
*// EXEC PGM=IKJEFT01,PARM='&CMD'*
*//SYSPROC DD DISP=SHR,DSN=your site sysproc libs// DD
...//SYSEXEC DD DISP=SHR,DSN=your site sysexec libs// DD
...//SYSTSPRT DD SYSOUT=**
*//SYSPRINT DD SYSOUT=* Not required, but commonly used.*
*//* Additional commands can be added via SYSTSIN*
*//SYSTSIN DD DDNAME=SYSIN In case you forget SYSTSIN DD *.*
*// PEND*
*//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
*// JCLLIB ORDER=(MY.JCL.LIB) Optional*
*// EXEC TSO*
*//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN use.*
*st*
*%myrexpgmalloc reuse dd(sysin) dummy*
*alloc reuse dd(sysut1) shr dsn(in.data)*
*alloc reuse dd(sysut2) mod dsn(out.data(results)) cyl space(10 10)
dsntype(library)*
*call *(iebgener)*
*//*
In general, all ALLOCs should include REUSE, since you maybe combining
multiple steps together or other programs might use the same DD. It
doesn't hurt.
- A REXX exec to allocate DB2 libraries if you need them. Accept an arg
string that identifies the environment if you need to, or interrogate some
external source of information.
- A REXX exec to invoke batch ISPF. Allocate all your ISP*LIBs and
ISPTABL. Take an arg string in the form of CMD(...), PGM(...) PARM(...),
or PANEL(...), and append it to ISPSTART. Only non-display panels are
valid in batch. Include a loop (DO 10 UNTIL RC <> 995; "ISPSTART"
arg(1); END) in case ISPSTART fails with a 995(?) on an ISPTABL enqueue
failure. You must VPUT ZISPFRC to get the return code passed up to the
caller (IKJEFT01).
- A REXX function to convert a relative GDG reference to an absolute
one. This will let you ALLOC a GDG member.
- An ALLOC wrapper function (in REXX) to check SYSDSN(), and determine
if the disposition should be NEW CATALOG or SHR, so you don't have to use
the finicky MOD. Then proceed with the "ALLOC REUSE DDNAME(...) ..." , and
return the RC of ALLOC. I would use ARG DDNAME DISP DSNAME OPTIONS to
receive blank delimited values. Separate concatenated DSNs with abutted
commas. A DISP value of "ASIS" could request the condition NEW/SHR
disposition. Loop over all the args the same way. If any allocation
fails, free them all.
This is your chance to join the 21st century.
I hope this helps.
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.
Post by Ward Able, Grant
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,
Post by Ward Able, Grant
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-----
Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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://secure-web.cisco.com/1vQAahM_WEN0g-
O0uf0FC49Sm1iZY1q5tU650TAzJAPfZA-6GgzWqmQIrZAGlNK4DGVa_
0OXF96LD1tkYz5MlkqTvdRNoNdhc5yjZrD9qmi5h2ES78_
bh08QhJNj9Tl8l6G5N2knmK6tZyBQ92hb-9vbFH0ehhFhpkXR9Tb00r2kuqUBUcc
dsMO2mnO2J3Psii1nswtaVb15FR7bbny20JeLJVyl3oO_T8ex9BQsdGjZHjJU4FVZTWv_
IAaTX5ghLP_FLAX1tyrEbLJ0BmKLSi7_bJ5UESdd6omyotG4JSVGJpY7p--
wbWa5JxyzSYgWpDcc9BjeSUVmx2POrXjBn-w6KLORmh5651iFW8d6mfHyJZ9pvQ4g
bB25w1DoQ06brrgi3Vu2fG8CU-7Pd-6uVQIZ7q-7f3Q0y1FjOJDEd6abDRR_
2QU3p-_TbFGVw4a96/http%3A%2F%2Fplanetmvs.com%2Frexxanywhere%2Findex.html
Post by Ward Able, Grant
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
Post by Ward Able, Grant
used it.
LINKPGM Like Assembler CALL with multiple Like Assembler CALL;
length halfwords not
arguments; length halfwords generated generated
automatically.
Post by Ward Able, Grant
automatically.
LINKMVS n/a Like Assembler CALL
with
Post by Ward Able, Grant
multiple
arguments; length halfwords generated
automatically. (This seems to be
z/VSE's LINKPGM.)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email
Post by Ward Able, Grant
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to
Post by Ward Able, Grant
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-07-09 16:23:41 UTC
Permalink
Raw Message
Post by Hobart Spitz
Post by Seymour J Metz
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
There were such statements as "I like JCL", or similar.
​And there are people who like Limburger cheese, too!​
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-09 16:33:33 UTC
Permalink
Raw Message
SLEEP is an example of the right answer to the wrong question. The problem is that you can't safely allocate a bunch of datasets that may potentially be used by other jobs.

As for PDSE, it in some ways makes the situation worse; concurrent jobs can update the same members, but in a different sequence, leading to bad updates.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Hobart Spitz <***@GMAIL.COM>
Sent: Monday, July 9, 2018 12:11 PM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Post by Seymour J Metz
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
There were such statements as "I like JCL", or similar.
Post by Seymour J Metz
2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.
I don't think anything I said was either.
Post by Seymour J Metz
2. Sleep does not address the deadly embrace problem.
I didn't claim that. It is needed to do your up front ENQs in REXX. You
still might have to exit with an error COND CODE if you can't get the ENQ
you need. A single ALLOC does not give the TSU a message or time to free
up the dataset.
Post by Seymour J Metz
3. PDSE does not solve the problem.
You'll have to explain that. From my reading of the doc., you can have
multiple readers and writers, in the same step or different JOBs opening
different members at the same time, provided the same member is not open
for OUTPUT by two different DCBs or JOBs/TSUs. All this with SHaRed
access, i.e. no DISP=OLD or equivalent. Note that I said, perhaps not
clearly enough, that the entire application, all foreground and background
accesses, must be SHaRed. What am I missing?

Thanks.
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Monday, July 9, 2018 8:46 AM
Subject: Re: REXX as JCL replacement
Post by Ward Able, Grant
What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?
I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away. The point is important, and the basis is a valid concern. The
conclusion is wrong. All it takes is understanding the problem and coming
up with creative solutions. As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.
One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts. This is
done to prevent a deadly embrace: JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y. JOB B has access to Y and needs
exclusive on X. Neither JOB can proceed until one is canceled, resulting
in lost production. Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.
Other repliers have answered Ward's question well, I was going to cut some
of the text out of my draft, but didn't. I think it is important to
understand what z/OS batch processing does, and where possible, why, so we
don't trivialize the effort or miss easy opportunities. I'll share my best
educated guesses with respect to the subject at hand.
When a batch JOB becomes eligible for execution these actions, relevant to
1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
3. ENQs are obtained on all datasets.
4. The EXECs for PGMs are processed, in order, one at a time.
So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions. These conventions could include the following, one or the
- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to
recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; see
also below on my first attempt at using REXX instead of JCL.
- Something else.
It might be helpful to know if, with all the changes and advancements,
deadly-embraces are still the issue it was in the 1960s-1980s. As I
explain below, an application that does not update any sequential datasets
or PDSs, does not have this as a major concern. E.g. an application where
all data updates are done to DB2 tables and PDSEs. Replace sequential
datasets and PDSs with PDSEs, even if there is only one member.
If you allow a dataset name to be set based on something only available
during execution time, there can be no initial ENQs, since the dataset name
is not known before the first step starts.
Further, z/OS batch processing in general, and initial ENQs, specifically,
lock in current customers due to the cost of porting and lack of equivalent
features elsewhere. Some smart developer may come to understand this and
provide the missing service. Some smart lawyer at a competitor might just
decide to take legal action on an anti-competitive basis. Either scenario
could represent an exposure to IBM (competitive or legal) and potential new
costs to customers. At the same time that existing customers are locked
in, new customers are locked out for the same reasons.
I'm going to provide some background, because, in some cases there are no
barriers to using REXX in batch.
That said, if your application does not update sequential or partitioned
datasets (in any JOB), then you can use REXX batch today, without any
significant risk of deadly-embrace or other problems. This would most
likely apply DB2 base applications, where all the DDs are for DB2 libraries
reference with DISP=SHR.
Give it a try. If you get down to just a fraction your previous
conventional JOBs, your management might get the idea that you are
onto something and change any fossilized mind-set about JCL.
If all your DISP='s are SHR, you may already have the opportunity to
streamline your application. This is not theory. I have done it, as I
describe in the next paragraph. AFAIK, you can code SHR for PDSEs in the
common cases. REWRITE/UPDATE in place is the main exception; you at least
get an abend in testing, unlike the scenario if you update-in-place a PDS
with DISP=SHR, and you just lose data.
(Apologies to anyone who has seen/heard this before. I'll abbreviate.) In
the early 1990s, I was working on a DB2 application that had hundreds of
JOB streams, most differing by 1 or more of 3 parameter values, phase,
client, and bill cycle. JOBs were submitted manually based on a visual
check of a DB2 table that tracked the current state of processing for each
batch process. Programs checked that same table to be sure that the
processing requested had passed the previous phase. All updates were to
DB2 tables. I determined that we could eliminate most of the JOBs and
automate processing with REXX and a DB2/REXX interface. We ended up with
less than 10 job streams, each of which would check for ready work, execute
the COBOL program for that work, and then loop back and look for more
work. Since the different phase processes could be executed in parallel
for different billing cycles and/or clients, one phase might complete
its work, making new work ready for the next phase via loopback check,
while the previous phase was being processed. Driving work from this phase
tracking table meant that we had automatic restart. If a process failed,
any needed corrective action would be taken, and the JCL resubmitted,
unchanged(!). Sometimes no resubmission was necessary if that phase was
already working. No RESTARTs to code, no PARMs to update, no dataset names
to override, and not third-party software.
This summarizes my thoughts on the JCL problems that REXX would address,
1. JCL creates an unnecessary, manditory, artificial, arbitrary, and
counter-productive distinction between scripting code and application
code. This the most important problem with JCL, and the hardest for single
platform staff and management to understand and accept. Under REXX, the
distinction entirely optional.
2. The communication between scripting (JCL) and application code is
limited. One (or some) strings in, and 4 digits (0-4095) out. TSO
supports return codes up to 16M, and REXX has no limit other than that
imposed by the invocation interface. The PARM= value can't come from a
file, DB2 table, or run-time expression. With REXX, these and other
options are available.
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, and has a steep
learning curve. That should be no surprise to anyone who has been paying
attention to the frequent questions about JCL on IBM-MAIN, and other
boards, that almost always get one of two answers: You can't do that, or
you have to do something weird and unintuitive. Using REXX, the syntax is
consistent, intuitive, powerful, and easy to use. The same expression
syntax is used everywhere.
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
5. JCL is a barrier to customers leaving z/OS, even for other IBM
platforms. Mixed news if you are a vendor.
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
11. Many of these limitations are addressed by complex work-arounds, or
expensive third-party packages that force you to work in a way dictated by
the software and not by your business requirements.
There may be other reasons.
Basically, JCL is so far from real a programming language, that I can't
describe it.
z/VM, like almost all other platforms, gets along swimmingly without a
separate batch language. You can issue CMS/zLinux/guest commands, or
invoke REXX programs to drive any batch process.
Replace your JCL with REXX a little at a time. Start with the low hanging
fruit and/or those that have automation requirements that are not addressed
in existing software. Focus on those that use DB2 table and PDSEs to store
data updates, and those JOBs that only have DISP=SHR. Replace updated PDSs
and sequential datasets with PDSEs, even if you only have one member. To
be really careful, make the changes so that you only have DISP-SHR in your
JCL. Once your are satisfied with that, replace the JCL with REXX. You
may have to experiment a bit. Post your questions if you are stuck.
JOB and any JESx control cards will mostly have to stay, and you will need
a TSO batch step. I recommend a PROC like this.
*//TSO PROC CMD=PROFILE*
*// EXEC PGM=IKJEFT01,PARM='&CMD'*
*//SYSPROC DD DISP=SHR,DSN=your site sysproc libs// DD
...//SYSEXEC DD DISP=SHR,DSN=your site sysexec libs// DD
...//SYSTSPRT DD SYSOUT=**
*//SYSPRINT DD SYSOUT=* Not required, but commonly used.*
*//* Additional commands can be added via SYSTSIN*
*//SYSTSIN DD DDNAME=SYSIN In case you forget SYSTSIN DD *.*
*// PEND*
*//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
*// JCLLIB ORDER=(MY.JCL.LIB) Optional*
*// EXEC TSO*
*//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN use.*
*st*
*%myrexpgmalloc reuse dd(sysin) dummy*
*alloc reuse dd(sysut1) shr dsn(in.data)*
*alloc reuse dd(sysut2) mod dsn(out.data(results)) cyl space(10 10)
dsntype(library)*
*call *(iebgener)*
*//*
In general, all ALLOCs should include REUSE, since you maybe combining
multiple steps together or other programs might use the same DD. It
doesn't hurt.
- A REXX exec to allocate DB2 libraries if you need them. Accept an arg
string that identifies the environment if you need to, or interrogate some
external source of information.
- A REXX exec to invoke batch ISPF. Allocate all your ISP*LIBs and
ISPTABL. Take an arg string in the form of CMD(...), PGM(...) PARM(...),
or PANEL(...), and append it to ISPSTART. Only non-display panels are
valid in batch. Include a loop (DO 10 UNTIL RC <> 995; "ISPSTART"
arg(1); END) in case ISPSTART fails with a 995(?) on an ISPTABL enqueue
failure. You must VPUT ZISPFRC to get the return code passed up to the
caller (IKJEFT01).
- A REXX function to convert a relative GDG reference to an absolute
one. This will let you ALLOC a GDG member.
- An ALLOC wrapper function (in REXX) to check SYSDSN(), and determine
if the disposition should be NEW CATALOG or SHR, so you don't have to use
the finicky MOD. Then proceed with the "ALLOC REUSE DDNAME(...) ..." , and
return the RC of ALLOC. I would use ARG DDNAME DISP DSNAME OPTIONS to
receive blank delimited values. Separate concatenated DSNs with abutted
commas. A DISP value of "ASIS" could request the condition NEW/SHR
disposition. Loop over all the args the same way. If any allocation
fails, free them all.
This is your chance to join the 21st century.
I hope this helps.
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.
Post by Ward Able, Grant
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,
Post by Ward Able, Grant
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-----
Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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://secure-web.cisco.com/1vQAahM_WEN0g-
O0uf0FC49Sm1iZY1q5tU650TAzJAPfZA-6GgzWqmQIrZAGlNK4DGVa_
0OXF96LD1tkYz5MlkqTvdRNoNdhc5yjZrD9qmi5h2ES78_
bh08QhJNj9Tl8l6G5N2knmK6tZyBQ92hb-9vbFH0ehhFhpkXR9Tb00r2kuqUBUcc
dsMO2mnO2J3Psii1nswtaVb15FR7bbny20JeLJVyl3oO_T8ex9BQsdGjZHjJU4FVZTWv_
IAaTX5ghLP_FLAX1tyrEbLJ0BmKLSi7_bJ5UESdd6omyotG4JSVGJpY7p--
wbWa5JxyzSYgWpDcc9BjeSUVmx2POrXjBn-w6KLORmh5651iFW8d6mfHyJZ9pvQ4g
bB25w1DoQ06brrgi3Vu2fG8CU-7Pd-6uVQIZ7q-7f3Q0y1FjOJDEd6abDRR_
2QU3p-_TbFGVw4a96/http%3A%2F%2Fplanetmvs.com%2Frexxanywhere%2Findex.html
Post by Ward Able, Grant
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
Post by Ward Able, Grant
used it.
LINKPGM Like Assembler CALL with multiple Like Assembler CALL;
length halfwords not
arguments; length halfwords generated generated
automatically.
Post by Ward Able, Grant
automatically.
LINKMVS n/a Like Assembler CALL
with
Post by Ward Able, Grant
multiple
arguments; length halfwords generated
automatically. (This seems to be
z/VSE's LINKPGM.)
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email
Post by Ward Able, Grant
DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity
to
Post by Ward Able, Grant
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage
caused by any virus transmitted by this email.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-07-09 16:56:14 UTC
Permalink
Raw Message
I'd like to point out that Hobart Spitz's long post is a great overview of
the practical and useful way that at least some JCL could be replaced with
REXX. The details can be nit-picked eternally (and no doubt will be).

sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ed Jaffe
2018-07-09 18:14:20 UTC
Permalink
Raw Message
Post by Seymour J Metz
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
Even Fred Brooks (who led the IBM team that invented JCL) calls it "the
worst programming language ever designed anywhere by anybody for any
purpose..."


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/

--------------------------------------------------------------------------------
This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-09 19:41:51 UTC
Permalink
Raw Message
[Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main
Post by Ed Jaffe
Post by Seymour J Metz
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
Even Fred Brooks (who led the IBM team that invented JCL) calls it "the
worst programming language ever designed anywhere by anybody for any
purpose..."
How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS
JCL compare with VSE JCL? My memories of DOS360 JCL probably are
irrelevant.

Clark Morris
Post by Ed Jaffe
http://youtu.be/8c0_Lzb1CJw
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-07-09 20:35:21 UTC
Permalink
Raw Message
WFL, Work Flow Language, actually. I had a very brief association with an employer's Burroughs 6500 long ago, and at the same time I actually wrote a term paper for an Operating Systems Survey course I was taking that compared WFL, MVS JCL and CDC6600 Control Language.

WFL was the clear winner by a huge margin.

Thanks for the lovely memory. I really enjoyed researching and writing that paper.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Clark Morris
Sent: Monday, July 9, 2018 3:42 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

[Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main
Post by Ed Jaffe
Post by Seymour J Metz
1. I don't recall anybody on IBM-MAIN claims that JCL is good.
Even Fred Brooks (who led the IBM team that invented JCL) calls it "the
worst programming language ever designed anywhere by anybody for any
purpose..."
How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS
JCL compare with VSE JCL? My memories of DOS360 JCL probably are
irrelevant.
--

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Ward Able, Grant
2018-07-10 09:12:43 UTC
Permalink
Raw Message
Seymour, I have to interject here and state that I like JCL. There - it is out in the open and I feel much better for having said it :-)
I am not going to say that it cannot be improved, of course it can, but I think it is a wonderful tool that has grown over the years, while HAVING to maintain most backward compatibility so it seems limited in how it can change, because of the need to maintain that compatibility.


Regards - Grant



DTCC Internal (Green)

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: 09 July 2018 16:10
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

ATTENTION! This email originated outside of DTCC; exercise caution.


1. I don't recall anybody on IBM-MAIN claims that JCL is good.

2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.

2. Sleep does not address the deadly embrace problem.

3. PDSE does not solve the problem.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Hobart Spitz <***@GMAIL.COM>
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Post by Ward Able, Grant
What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on which many people base their thinking that JCL is good and may never go away. The point is important, and the basis is a valid concern. The conclusion is wrong. All it takes is understanding the problem and coming up with creative solutions. As I describe below, DB2 based applications and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the entire JOB are obtained before any step execution actually starts. This is done to prevent a deadly embrace: JOB A has exclusive access to dataset X and needs exclusive access to dataset Y. JOB B has access to Y and needs exclusive on X. Neither JOB can proceed until one is canceled, resulting in lost production. Despite this being a useful service, there is no TSO equivalent, either via a parallel ENQs (as Seymour suggested) or a standard SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some of the text out of my draft, but didn't. I think it is important to understand what z/OS batch processing does, and where possible, why, so we don't trivialize the effort or miss easy opportunities. I'll share my best educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to our subject, happen in this order:

1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
3. ENQs are obtained on all datasets.
4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or commit to not changing DSNs during processing, or observe certain conventions. These conventions could include the following, one or the other may be appropriate depending on the applications' needs:

- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; see
also below on my first attempt at using REXX instead of JCL.
- Something else.

It might be helpful to know if, with all the changes and advancements, deadly-embraces are still the issue it was in the 1960s-1980s. As I explain below, an application that does not update any sequential datasets or PDSs, does not have this as a major concern. E.g. an application where all data updates are done to DB2 tables and PDSEs. Replace sequential datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available during execution time, there can be no initial ENQs, since the dataset name is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically, lock in current customers due to the cost of porting and lack of equivalent features elsewhere. Some smart developer may come to understand this and provide the missing service. Some smart lawyer at a competitor might just decide to take legal action on an anti-competitive basis. Either scenario could represent an exposure to IBM (competitive or legal) and potential new costs to customers. At the same time that existing customers are locked in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned datasets (in any JOB), then you can use REXX batch today, without any significant risk of deadly-embrace or other problems. This would most likely apply DB2 base applications, where all the DDs are for DB2 libraries reference with DISP=SHR.

Give it a try. If you get down to just a fraction your previous conventional JOBs, your management might get the idea that you are onto something and change any fossilized mind-set about JCL.

If all your DISP='s are SHR, you may already have the opportunity to streamline your application. This is not theory. I have done it, as I describe in the next paragraph. AFAIK, you can code SHR for PDSEs in the common cases. REWRITE/UPDATE in place is the main exception; you at least get an abend in testing, unlike the scenario if you update-in-place a PDS with DISP=SHR, and you just lose data.

(Apologies to anyone who has seen/heard this before. I'll abbreviate.) In the early 1990s, I was working on a DB2 application that had hundreds of JOB streams, most differing by 1 or more of 3 parameter values, phase, client, and bill cycle. JOBs were submitted manually based on a visual check of a DB2 table that tracked the current state of processing for each batch process. Programs checked that same table to be sure that the processing requested had passed the previous phase. All updates were to
DB2 tables. I determined that we could eliminate most of the JOBs and automate processing with REXX and a DB2/REXX interface. We ended up with less than 10 job streams, each of which would check for ready work, execute the COBOL program for that work, and then loop back and look for more work. Since the different phase processes could be executed in parallel for different billing cycles and/or clients, one phase might complete its work, making new work ready for the next phase via loopback check, while the previous phase was being processed. Driving work from this phase tracking table meant that we had automatic restart. If a process failed, any needed corrective action would be taken, and the JCL resubmitted, unchanged(!). Sometimes no resubmission was necessary if that phase was already working. No RESTARTs to code, no PARMs to update, no dataset names to override, and not third-party software.

This summarizes my thoughts on the JCL problems that REXX would address, per Ward's request:

1. JCL creates an unnecessary, manditory, artificial, arbitrary, and
counter-productive distinction between scripting code and application
code. This the most important problem with JCL, and the hardest for single
platform staff and management to understand and accept. Under REXX, the
distinction entirely optional.
2. The communication between scripting (JCL) and application code is
limited. One (or some) strings in, and 4 digits (0-4095) out. TSO
supports return codes up to 16M, and REXX has no limit other than that
imposed by the invocation interface. The PARM= value can't come from a
file, DB2 table, or run-time expression. With REXX, these and other
options are available.
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, and has a steep
learning curve. That should be no surprise to anyone who has been paying
attention to the frequent questions about JCL on IBM-MAIN, and other
boards, that almost always get one of two answers: You can't do that, or
you have to do something weird and unintuitive. Using REXX, the syntax is
consistent, intuitive, powerful, and easy to use. The same expression
syntax is used everywhere.
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
5. JCL is a barrier to customers leaving z/OS, even for other IBM
platforms. Mixed news if you are a vendor.
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
11. Many of these limitations are addressed by complex work-arounds, or
expensive third-party packages that force you to work in a way dictated by
the software and not by your business requirements.

There may be other reasons.

Basically, JCL is so far from real a programming language, that I can't describe it.

z/VM, like almost all other platforms, gets along swimmingly without a separate batch language. You can issue CMS/zLinux/guest commands, or invoke REXX programs to drive any batch process.

Replace your JCL with REXX a little at a time. Start with the low hanging fruit and/or those that have automation requirements that are not addressed in existing software. Focus on those that use DB2 table and PDSEs to store data updates, and those JOBs that only have DISP=SHR. Replace updated PDSs and sequential datasets with PDSEs, even if you only have one member. To be really careful, make the changes so that you only have DISP-SHR in your JCL. Once your are satisfied with that, replace the JCL with REXX. You may have to experiment a bit. Post your questions if you are stuck.

JOB and any JESx control cards will mostly have to stay, and you will need a TSO batch step. I recommend a PROC like this.

*//TSO PROC CMD=PROFILE*
*// EXEC PGM=IKJEFT01,PARM='&CMD'*
*//SYSPROC DD DISP=SHR,DSN=your site sysproc libs// DD
...//SYSEXEC DD DISP=SHR,DSN=your site sysexec libs// DD
...//SYSTSPRT DD SYSOUT=**
*//SYSPRINT DD SYSOUT=* Not required, but commonly used.*
*//* Additional commands can be added via SYSTSIN*
*//SYSTSIN DD DDNAME=SYSIN In case you forget SYSTSIN DD *.*
*// PEND*

It can be invoked thusly:

*//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
*// JCLLIB ORDER=(MY.JCL.LIB) Optional*
*// EXEC TSO*
*//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN use.*
*st*

*%myrexpgmalloc reuse dd(sysin) dummy*
*alloc reuse dd(sysut1) shr dsn(in.data)* *alloc reuse dd(sysut2) mod dsn(out.data(results)) cyl space(10 10)
dsntype(library)*
*call *(iebgener)*
*//*

In general, all ALLOCs should include REUSE, since you maybe combining multiple steps together or other programs might use the same DD. It doesn't hurt.

Other handy things to add as you need them:

- A REXX exec to allocate DB2 libraries if you need them. Accept an arg
string that identifies the environment if you need to, or interrogate some
external source of information.
- A REXX exec to invoke batch ISPF. Allocate all your ISP*LIBs and
ISPTABL. Take an arg string in the form of CMD(...), PGM(...) PARM(...),
or PANEL(...), and append it to ISPSTART. Only non-display panels are
valid in batch. Include a loop (DO 10 UNTIL RC <> 995; "ISPSTART"
arg(1); END) in case ISPSTART fails with a 995(?) on an ISPTABL enqueue
failure. You must VPUT ZISPFRC to get the return code passed up to the
caller (IKJEFT01).
- A REXX function to convert a relative GDG reference to an absolute
one. This will let you ALLOC a GDG member.
- An ALLOC wrapper function (in REXX) to check SYSDSN(), and determine
if the disposition should be NEW CATALOG or SHR, so you don't have to use
the finicky MOD. Then proceed with the "ALLOC REUSE DDNAME(...) ..." , and
return the RC of ALLOC. I would use ARG DDNAME DISP DSNAME OPTIONS to
receive blank delimited values. Separate concatenated DSNs with abutted
commas. A DISP value of "ASIS" could request the condition NEW/SHR
disposition. Loop over all the args the same way. If any allocation
fails, free them all.

This is your chance to join the 21st century.

I hope this helps.

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.
Post by Ward Able, Grant
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-----
On Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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://secure-web.cisco.com/1vQAahM_WEN0g-O0uf0FC49Sm1iZY1q5tU650TAzJA
PfZA-6GgzWqmQIrZAGlNK4DGVa_0OXF96LD1tkYz5MlkqTvdRNoNdhc5yjZrD9qmi5h2ES
78_bh08QhJNj9Tl8l6G5N2knmK6tZyBQ92hb-9vbFH0ehhFhpkXR9Tb00r2kuqUBUccdsM
O2mnO2J3Psii1nswtaVb15FR7bbny20JeLJVyl3oO_T8ex9BQsdGjZHjJU4FVZTWv_IAaT
X5ghLP_FLAX1tyrEbLJ0BmKLSi7_bJ5UESdd6omyotG4JSVGJpY7p--wbWa5JxyzSYgWpD
cc9BjeSUVmx2POrXjBn-w6KLORmh5651iFW8d6mfHyJZ9pvQ4gbB25w1DoQ06brrgi3Vu2
fG8CU-7Pd-6uVQIZ7q-7f3Q0y1FjOJDEd6abDRR_2QU3p-_TbFGVw4a96/http%3A%2F%2
Fplanetmvs.com%2Frexxanywhere%2Findex.html
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email in
error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company accepts
no liability for any damage caused by any virus transmitted by this email.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-10 15:23:26 UTC
Permalink
Raw Message
Post by Ward Able, Grant
Seymour, I have to interject here and state that I like JCL.
De Gustibus Non Est Disputandum said the old lady as she kissed the cow. For me it's more like the water in Gunga Din.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Ward Able, Grant <***@DTCC.COM>
Sent: Tuesday, July 10, 2018 5:12 AM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Seymour, I have to interject here and state that I like JCL. There - it is out in the open and I feel much better for having said it :-)
I am not going to say that it cannot be improved, of course it can, but I think it is a wonderful tool that has grown over the years, while HAVING to maintain most backward compatibility so it seems limited in how it can change, because of the need to maintain that compatibility.


Regards - Grant



DTCC Internal (Green)

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz
Sent: 09 July 2018 16:10
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

ATTENTION! This email originated outside of DTCC; exercise caution.


1. I don't recall anybody on IBM-MAIN claims that JCL is good.

2. Creative solutions are good if they solve the actual problem, not
just an imaginary or irrelevant one.

2. Sleep does not address the deadly embrace problem.

3. PDSE does not solve the problem.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Hobart Spitz <***@GMAIL.COM>
Sent: Monday, July 9, 2018 8:46 AM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement
Post by Ward Able, Grant
What are the problems (perceived or real) that will be resolved by
replacing JCL with REXX?

I think that it's important to first understand the characteristics on which many people base their thinking that JCL is good and may never go away. The point is important, and the basis is a valid concern. The conclusion is wrong. All it takes is understanding the problem and coming up with creative solutions. As I describe below, DB2 based applications and those that use only PDSEs are likely to be good starting points.

One valuable feature of z/OS batch processing is that all ENQs for the entire JOB are obtained before any step execution actually starts. This is done to prevent a deadly embrace: JOB A has exclusive access to dataset X and needs exclusive access to dataset Y. JOB B has access to Y and needs exclusive on X. Neither JOB can proceed until one is canceled, resulting in lost production. Despite this being a useful service, there is no TSO equivalent, either via a parallel ENQs (as Seymour suggested) or a standard SLEEP mechanism to allow for retries.

Other repliers have answered Ward's question well, I was going to cut some of the text out of my draft, but didn't. I think it is important to understand what z/OS batch processing does, and where possible, why, so we don't trivialize the effort or miss easy opportunities. I'll share my best educated guesses with respect to the subject at hand.

When a batch JOB becomes eligible for execution these actions, relevant to our subject, happen in this order:

1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
3. ENQs are obtained on all datasets.
4. The EXECs for PGMs are processed, in order, one at a time.

So any REXX implementation would have either to forgo do initial ENQs, or commit to not changing DSNs during processing, or observe certain conventions. These conventions could include the following, one or the other may be appropriate depending on the applications' needs:

- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; see
also below on my first attempt at using REXX instead of JCL.
- Something else.

It might be helpful to know if, with all the changes and advancements, deadly-embraces are still the issue it was in the 1960s-1980s. As I explain below, an application that does not update any sequential datasets or PDSs, does not have this as a major concern. E.g. an application where all data updates are done to DB2 tables and PDSEs. Replace sequential datasets and PDSs with PDSEs, even if there is only one member.

If you allow a dataset name to be set based on something only available during execution time, there can be no initial ENQs, since the dataset name is not known before the first step starts.

Further, z/OS batch processing in general, and initial ENQs, specifically, lock in current customers due to the cost of porting and lack of equivalent features elsewhere. Some smart developer may come to understand this and provide the missing service. Some smart lawyer at a competitor might just decide to take legal action on an anti-competitive basis. Either scenario could represent an exposure to IBM (competitive or legal) and potential new costs to customers. At the same time that existing customers are locked in, new customers are locked out for the same reasons.

I'm going to provide some background, because, in some cases there are no barriers to using REXX in batch.

That said, if your application does not update sequential or partitioned datasets (in any JOB), then you can use REXX batch today, without any significant risk of deadly-embrace or other problems. This would most likely apply DB2 base applications, where all the DDs are for DB2 libraries reference with DISP=SHR.

Give it a try. If you get down to just a fraction your previous conventional JOBs, your management might get the idea that you are onto something and change any fossilized mind-set about JCL.

If all your DISP='s are SHR, you may already have the opportunity to streamline your application. This is not theory. I have done it, as I describe in the next paragraph. AFAIK, you can code SHR for PDSEs in the common cases. REWRITE/UPDATE in place is the main exception; you at least get an abend in testing, unlike the scenario if you update-in-place a PDS with DISP=SHR, and you just lose data.

(Apologies to anyone who has seen/heard this before. I'll abbreviate.) In the early 1990s, I was working on a DB2 application that had hundreds of JOB streams, most differing by 1 or more of 3 parameter values, phase, client, and bill cycle. JOBs were submitted manually based on a visual check of a DB2 table that tracked the current state of processing for each batch process. Programs checked that same table to be sure that the processing requested had passed the previous phase. All updates were to
DB2 tables. I determined that we could eliminate most of the JOBs and automate processing with REXX and a DB2/REXX interface. We ended up with less than 10 job streams, each of which would check for ready work, execute the COBOL program for that work, and then loop back and look for more work. Since the different phase processes could be executed in parallel for different billing cycles and/or clients, one phase might complete its work, making new work ready for the next phase via loopback check, while the previous phase was being processed. Driving work from this phase tracking table meant that we had automatic restart. If a process failed, any needed corrective action would be taken, and the JCL resubmitted, unchanged(!). Sometimes no resubmission was necessary if that phase was already working. No RESTARTs to code, no PARMs to update, no dataset names to override, and not third-party software.

This summarizes my thoughts on the JCL problems that REXX would address, per Ward's request:

1. JCL creates an unnecessary, manditory, artificial, arbitrary, and
counter-productive distinction between scripting code and application
code. This the most important problem with JCL, and the hardest for single
platform staff and management to understand and accept. Under REXX, the
distinction entirely optional.
2. The communication between scripting (JCL) and application code is
limited. One (or some) strings in, and 4 digits (0-4095) out. TSO
supports return codes up to 16M, and REXX has no limit other than that
imposed by the invocation interface. The PARM= value can't come from a
file, DB2 table, or run-time expression. With REXX, these and other
options are available.
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, and has a steep
learning curve. That should be no surprise to anyone who has been paying
attention to the frequent questions about JCL on IBM-MAIN, and other
boards, that almost always get one of two answers: You can't do that, or
you have to do something weird and unintuitive. Using REXX, the syntax is
consistent, intuitive, powerful, and easy to use. The same expression
syntax is used everywhere.
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
5. JCL is a barrier to customers leaving z/OS, even for other IBM
platforms. Mixed news if you are a vendor.
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
11. Many of these limitations are addressed by complex work-arounds, or
expensive third-party packages that force you to work in a way dictated by
the software and not by your business requirements.

There may be other reasons.

Basically, JCL is so far from real a programming language, that I can't describe it.

z/VM, like almost all other platforms, gets along swimmingly without a separate batch language. You can issue CMS/zLinux/guest commands, or invoke REXX programs to drive any batch process.

Replace your JCL with REXX a little at a time. Start with the low hanging fruit and/or those that have automation requirements that are not addressed in existing software. Focus on those that use DB2 table and PDSEs to store data updates, and those JOBs that only have DISP=SHR. Replace updated PDSs and sequential datasets with PDSEs, even if you only have one member. To be really careful, make the changes so that you only have DISP-SHR in your JCL. Once your are satisfied with that, replace the JCL with REXX. You may have to experiment a bit. Post your questions if you are stuck.

JOB and any JESx control cards will mostly have to stay, and you will need a TSO batch step. I recommend a PROC like this.

*//TSO PROC CMD=PROFILE*
*// EXEC PGM=IKJEFT01,PARM='&CMD'*
*//SYSPROC DD DISP=SHR,DSN=your site sysproc libs// DD
...//SYSEXEC DD DISP=SHR,DSN=your site sysexec libs// DD
...//SYSTSPRT DD SYSOUT=**
*//SYSPRINT DD SYSOUT=* Not required, but commonly used.*
*//* Additional commands can be added via SYSTSIN*
*//SYSTSIN DD DDNAME=SYSIN In case you forget SYSTSIN DD *.*
*// PEND*

It can be invoked thusly:

*//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
*// JCLLIB ORDER=(MY.JCL.LIB) Optional*
*// EXEC TSO*
*//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN use.*
*st*

*%myrexpgmalloc reuse dd(sysin) dummy*
*alloc reuse dd(sysut1) shr dsn(in.data)* *alloc reuse dd(sysut2) mod dsn(out.data(results)) cyl space(10 10)
dsntype(library)*
*call *(iebgener)*
*//*

In general, all ALLOCs should include REUSE, since you maybe combining multiple steps together or other programs might use the same DD. It doesn't hurt.

Other handy things to add as you need them:

- A REXX exec to allocate DB2 libraries if you need them. Accept an arg
string that identifies the environment if you need to, or interrogate some
external source of information.
- A REXX exec to invoke batch ISPF. Allocate all your ISP*LIBs and
ISPTABL. Take an arg string in the form of CMD(...), PGM(...) PARM(...),
or PANEL(...), and append it to ISPSTART. Only non-display panels are
valid in batch. Include a loop (DO 10 UNTIL RC <> 995; "ISPSTART"
arg(1); END) in case ISPSTART fails with a 995(?) on an ISPTABL enqueue
failure. You must VPUT ZISPFRC to get the return code passed up to the
caller (IKJEFT01).
- A REXX function to convert a relative GDG reference to an absolute
one. This will let you ALLOC a GDG member.
- An ALLOC wrapper function (in REXX) to check SYSDSN(), and determine
if the disposition should be NEW CATALOG or SHR, so you don't have to use
the finicky MOD. Then proceed with the "ALLOC REUSE DDNAME(...) ..." , and
return the RC of ALLOC. I would use ARG DDNAME DISP DSNAME OPTIONS to
receive blank delimited values. Separate concatenated DSNs with abutted
commas. A DISP value of "ASIS" could request the condition NEW/SHR
disposition. Loop over all the args the same way. If any allocation
fails, free them all.

This is your chance to join the 21st century.

I hope this helps.

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.
Post by Ward Able, Grant
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-----
On Behalf Of Paul Gilmartin
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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://secure-web.cisco.com/1vQAahM_WEN0g-O0uf0FC49Sm1iZY1q5tU650TAzJA
PfZA-6GgzWqmQIrZAGlNK4DGVa_0OXF96LD1tkYz5MlkqTvdRNoNdhc5yjZrD9qmi5h2ES
78_bh08QhJNj9Tl8l6G5N2knmK6tZyBQ92hb-9vbFH0ehhFhpkXR9Tb00r2kuqUBUccdsM
O2mnO2J3Psii1nswtaVb15FR7bbny20JeLJVyl3oO_T8ex9BQsdGjZHjJU4FVZTWv_IAaT
X5ghLP_FLAX1tyrEbLJ0BmKLSi7_bJ5UESdd6omyotG4JSVGJpY7p--wbWa5JxyzSYgWpD
cc9BjeSUVmx2POrXjBn-w6KLORmh5651iFW8d6mfHyJZ9pvQ4gbB25w1DoQ06brrgi3Vu2
fG8CU-7Pd-6uVQIZ7q-7f3Q0y1FjOJDEd6abDRR_2QU3p-_TbFGVw4a96/http%3A%2F%2
Fplanetmvs.com%2Frexxanywhere%2Findex.html
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or
entity to whom they are addressed. If you have received this email in
error, please notify us immediately and delete the email and any
attachments from your system. The recipient should check this email
and any attachments for the presence of viruses. The company accepts
no liability for any damage caused by any virus transmitted by this email.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
DTCC DISCLAIMER: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify us immediately and delete the email and any attachments from your system. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Andrew Rowley
2018-07-09 23:15:35 UTC
Permalink
Raw Message
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML, XML,
JSON, but that's not what they are supposed to be.

JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in itself:
you have a job, which has steps, steps have DDs etc. The syntax is old
fashioned, but the concepts are very much OOP. It would be relatively
simple to create a set of classes in your OOP language of choice to hide
the syntax - just create a Job object, add Step objects, add
DataDefinition objects etc. and have a Submit method emit JCL.

If I want to write a program, I will choose a programming language. If I
want to define a unit of work to the system, JCL does a pretty good job.
I definitely prefer JCL to long command lines with multiple switches and
options defining input and output files, which is the non-z/OS equivalent.

Andrew Rowley
Black Hill Software

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-09 23:45:10 UTC
Permalink
Raw Message
I wrote a product that as part of its processing generated JCL. (It was a side chore; it was not a "JCL-generator.") And yes, JCL mapped really well to an OOP sort of approach. Within DDs you have positional operand classes and keyword operand classes, and then various children of those, and so forth.

RECFM objects stood on their own, so an abstract file object could have a RECFM, and then you could assign that RECFM object to a DD statement for that file.

It sounds weird but it actually mapped quite well.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley
Sent: Monday, July 9, 2018 4:15 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML, XML,
JSON, but that's not what they are supposed to be.

JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in itself:
you have a job, which has steps, steps have DDs etc. The syntax is old
fashioned, but the concepts are very much OOP. It would be relatively
simple to create a set of classes in your OOP language of choice to hide
the syntax - just create a Job object, add Step objects, add
DataDefinition objects etc. and have a Submit method emit JCL.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-07-10 00:11:30 UTC
Permalink
Raw Message
Ed Jaffe posted a video... it seems he worked some magic on it so that it's
only an excerpt from a longer presentation. It runs about 5 minutes, and
it's well worth that. Frederick P. Brooks had many talents, one of which
is he's an engaging and funny speaker.

The upshot (for our purposes) of his talk was that while they had a lot of
smart people designing some smart languages, JCL somehow appeared without
ever being planned or designed. He *emphatically* states it's "the worst
language ever created, for any purpose, ever". Twice, if I counted
correctly.

Learning JCL is like learning Sheephead... at some point, you start to
think people are just making sh*t up as they go along. Come to think of
it, I think they probably did.

I've probably said this before, but I like JCL too, it's an interesting
puzzle-solving thing, like sudoku. But I never thought it was the "right"
way to do it.

sas
Post by Andrew Rowley
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML, XML,
JSON, but that's not what they are supposed to be.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2018-07-10 01:32:39 UTC
Permalink
Raw Message
Post by Andrew Rowley
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML,
XML, JSON, but that's not what they are supposed to be.
Java Batch (JSR 352) has basically re-implemented JCL using XML. Now
that must really suck!
Post by Andrew Rowley
JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in
itself: you have a job, which has steps, steps have DDs etc. The
syntax is old fashioned, but the concepts are very much OOP. It would
be relatively simple to create a set of classes in your OOP language
of choice to hide the syntax - just create a Job object, add Step
objects, add DataDefinition objects etc. and have a Submit method emit
JCL.
If I want to write a program, I will choose a programming language. If
I want to define a unit of work to the system, JCL does a pretty good
job. I definitely prefer JCL to long command lines with multiple
switches and options defining input and output files, which is the
non-z/OS equivalent.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Roger W Suhr
2018-07-10 15:31:07 UTC
Permalink
Raw Message
I agree with David Crayford's comment, 100%!
Let's put this to rest. To completely replace JCL with REXX is not an option. If you want to run certain applications driven by REXX program, by my guest, that's a design issue. But please don't plan on replacing everything with REXX.

Roger W. Suhr
***@gmail.com


-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of David Crayford
Sent: Monday, July 9, 2018 21:32
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Post by Andrew Rowley
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I
can't describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML,
XML, JSON, but that's not what they are supposed to be.
Java Batch (JSR 352) has basically re-implemented JCL using XML. Now that must really suck!
Post by Andrew Rowley
JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in
itself: you have a job, which has steps, steps have DDs etc. The
syntax is old fashioned, but the concepts are very much OOP. It would
be relatively simple to create a set of classes in your OOP language
of choice to hide the syntax - just create a Job object, add Step
objects, add DataDefinition objects etc. and have a Submit method emit
JCL.
If I want to write a program, I will choose a programming language. If
I want to define a unit of work to the system, JCL does a pretty good
job. I definitely prefer JCL to long command lines with multiple
switches and options defining input and output files, which is the
non-z/OS equivalent.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clem Clarke
2018-07-11 00:34:00 UTC
Permalink
Raw Message
Below is an example of Jol, and the equivalent JCL.

Clem

Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows

Payroll: Job class C 1000 k;
Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
if Validate=0
then do;
    Sort transaction(+1) to Sorted.Trans.Actions(+1)
        Fields(10,10,CH,A);
    Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
        Payroll.Master(+1);
    If Update = 0
    then do;
        Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
        Submit Job2;
    end;
end;
else Stop 'Error in PAYROLL Job';


________________________________

Equivalent Existing Job Control Language


//PAYROLL   JOB      CLASS=C,REGION=1000K
//VALIDATE   EXEC     PGM=VALIDATE
//SYSPRINT   DD       SYSOUT=*
//INTRANS    DD       DSN=INPUT.TRANS,DISP=SHR
//OUTTRANS   DD       DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
//                    DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//                    SPACE=(CYL,(10,10),RLSE),
//                    UNIT=SYSDA,VOL=SER=WORK01
//SORT       EXEC     PGM=SORT,COND=(VALIDATE,NE,0)
//SYSOUT     DD       SYSOUT=*
//SORTWK01   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK02   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK03   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTIN     DD       DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
//SORTOUT    DD       DSN=SORTED.TRANS.ACTIONS(+1),
//                    DISP=(NEW,PASS),
//                    DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//                    SPACE=(CYL,(10,10),RLSE),
//                    UNIT=SYSDA,VOL=SER=WORK01
//SYSIN      DD   *
        SORT FIELDS=(10,10,CH,A)
//UPDATE     EXEC     PGM=UPDATE,COND=(VALIDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//MASTIN     DD       DSN=PAYROLL.MASTER(0),DISP=SHR
//TRANS      DD       DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
//MASTOUT    DD       DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
//                    DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//                    SPACE=(CYL,(10,10),RLSE),
//                    UNIT=SYSDA,VOL=SER=WORK01
//CATLG      EXEC     PGM=IEFBR14,COND=(UPDATE,NE,0)
//DUMMY1     DD       DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
//DUMMY2     DD       DSN=SORTED.TRANS.ACTIONS(+1),
//                    DISP=(SHR,CATLG)
//SUBMIT     EXEC     PGM=IEBGENER,COND=(UPDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//SYSUT1     DD       DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
//SYSUT2     DD       SYSOUT=(*,INTRDR)
//SYSIN      DD       DUMMY
//ERRMSG     EXEC     PGM=SHOWERR,COND=(VALIDATE,EQ,0),
//           PARM='Error in PAYROLL Job'
Post by Andrew Rowley
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML,
XML, JSON, but that's not what they are supposed to be.
JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in
itself: you have a job, which has steps, steps have DDs etc. The
syntax is old fashioned, but the concepts are very much OOP. It would
be relatively simple to create a set of classes in your OOP language
of choice to hide the syntax - just create a Job object, add Step
objects, add DataDefinition objects etc. and have a Submit method emit
JCL.
If I want to write a program, I will choose a programming language. If
I want to define a unit of work to the system, JCL does a pretty good
job. I definitely prefer JCL to long command lines with multiple
switches and options defining input and output files, which is the
non-z/OS equivalent.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-11 10:09:34 UTC
Permalink
Raw Message
So where does JOL get all the other informatoin for the DD card? Is
there some back-end database that has information for all the files that
may be used?

Tony Thigpen
Post by Clem Clarke
Below is an example of Jol, and the equivalent JCL.
Clem
Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
Payroll: Job class C 1000 k;
Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
if Validate=0
then do;
    Sort transaction(+1) to Sorted.Trans.Actions(+1)
        Fields(10,10,CH,A);
    Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
        Payroll.Master(+1);
    If Update = 0
    then do;
        Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
        Submit Job2;
    end;
end;
else Stop 'Error in PAYROLL Job';
________________________________
Equivalent Existing Job Control Language
//PAYROLL   JOB      CLASS=C,REGION=1000K
//VALIDATE   EXEC     PGM=VALIDATE
//SYSPRINT   DD       SYSOUT=*
//INTRANS    DD       DSN=INPUT.TRANS,DISP=SHR
//OUTTRANS   DD       DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
//                    DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//                    SPACE=(CYL,(10,10),RLSE),
//                    UNIT=SYSDA,VOL=SER=WORK01
//SORT       EXEC     PGM=SORT,COND=(VALIDATE,NE,0)
//SYSOUT     DD       SYSOUT=*
//SORTWK01   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK02   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK03   DD       UNIT=SYSDA,SPACE=(CYL,20)
//SORTIN     DD       DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
//SORTOUT    DD       DSN=SORTED.TRANS.ACTIONS(+1),
//                    DISP=(NEW,PASS),
//                    DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//                    SPACE=(CYL,(10,10),RLSE),
//                    UNIT=SYSDA,VOL=SER=WORK01
//SYSIN      DD   *
        SORT FIELDS=(10,10,CH,A)
//UPDATE     EXEC     PGM=UPDATE,COND=(VALIDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//MASTIN     DD       DSN=PAYROLL.MASTER(0),DISP=SHR
//TRANS      DD       DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
//MASTOUT    DD       DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
//                    DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
//                    SPACE=(CYL,(10,10),RLSE),
//                    UNIT=SYSDA,VOL=SER=WORK01
//CATLG      EXEC     PGM=IEFBR14,COND=(UPDATE,NE,0)
//DUMMY1     DD       DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
//DUMMY2     DD       DSN=SORTED.TRANS.ACTIONS(+1),
//                    DISP=(SHR,CATLG)
//SUBMIT     EXEC     PGM=IEBGENER,COND=(UPDATE,NE,0)
//SYSPRINT   DD       SYSOUT=*
//SYSUT1     DD       DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
//SYSUT2     DD       SYSOUT=(*,INTRDR)
//SYSIN      DD       DUMMY
//ERRMSG     EXEC     PGM=SHOWERR,COND=(VALIDATE,EQ,0),
//           PARM='Error in PAYROLL Job'
Post by Andrew Rowley
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML,
XML, JSON, but that's not what they are supposed to be.
JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in
itself: you have a job, which has steps, steps have DDs etc. The
syntax is old fashioned, but the concepts are very much OOP. It would
be relatively simple to create a set of classes in your OOP language
of choice to hide the syntax - just create a Job object, add Step
objects, add DataDefinition objects etc. and have a Submit method emit
JCL.
If I want to write a program, I will choose a programming language. If
I want to define a unit of work to the system, JCL does a pretty good
job. I definitely prefer JCL to long command lines with multiple
switches and options defining input and output files, which is the
non-z/OS equivalent.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
ITschak Mugzach
2018-07-11 10:20:23 UTC
Permalink
Raw Message
Speaking of replacing JCL, how about unisys WFL? It's a programming
language dedicated to job flows. BTW, I am happy with jcl...

ITschak
Post by Tony Thigpen
So where does JOL get all the other informatoin for the DD card? Is
there some back-end database that has information for all the files that
may be used?
Tony Thigpen
Post by Clem Clarke
Below is an example of Jol, and the equivalent JCL.
Clem
Simplified Jol Scripting Language for Z/OS, TSO, Linux and Windows
Payroll: Job class C 1000 k;
Exec Validate Input.Trans, Trans.Action(+1); /* Validate Transations */
if Validate=0
then do;
Sort transaction(+1) to Sorted.Trans.Actions(+1)
Fields(10,10,CH,A);
Exec Update Payroll.Master(0), Sorted.Trans.Action(+1),
Payroll.Master(+1);
If Update = 0
then do;
Catalog Payroll.Master(+1), Sorted.Trans.Action(+1);
Submit Job2;
end;
end;
else Stop 'Error in PAYROLL Job';
________________________________
Equivalent Existing Job Control Language
//PAYROLL JOB CLASS=C,REGION=1000K
//VALIDATE EXEC PGM=VALIDATE
//SYSPRINT DD SYSOUT=*
//INTRANS DD DSN=INPUT.TRANS,DISP=SHR
//OUTTRANS DD DSN=TRANS.ACTIONS(+1),DISP=(NEW,PASS),
// DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
// SPACE=(CYL,(10,10),RLSE),
// UNIT=SYSDA,VOL=SER=WORK01
//SORT EXEC PGM=SORT,COND=(VALIDATE,NE,0)
//SYSOUT DD SYSOUT=*
//SORTWK01 DD UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK02 DD UNIT=SYSDA,SPACE=(CYL,20)
//SORTWK03 DD UNIT=SYSDA,SPACE=(CYL,20)
//SORTIN DD DSN=TRANS.ACTIONS(+1),DISP=(SHR,PASS)
//SORTOUT DD DSN=SORTED.TRANS.ACTIONS(+1),
// DISP=(NEW,PASS),
// DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
// SPACE=(CYL,(10,10),RLSE),
// UNIT=SYSDA,VOL=SER=WORK01
//SYSIN DD *
SORT FIELDS=(10,10,CH,A)
//UPDATE EXEC PGM=UPDATE,COND=(VALIDATE,NE,0)
//SYSPRINT DD SYSOUT=*
//MASTIN DD DSN=PAYROLL.MASTER(0),DISP=SHR
//TRANS DD DSN=TRANS.ACTION(+1),DISP=(SHR,PASS)
//MASTOUT DD DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS),
// DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030),
// SPACE=(CYL,(10,10),RLSE),
// UNIT=SYSDA,VOL=SER=WORK01
//CATLG EXEC PGM=IEFBR14,COND=(UPDATE,NE,0)
//DUMMY1 DD DSN=PAYROLL.MASTER(+1),DISP=(SHR,CATLG)
//DUMMY2 DD DSN=SORTED.TRANS.ACTIONS(+1),
// DISP=(SHR,CATLG)
//SUBMIT EXEC PGM=IEBGENER,COND=(UPDATE,NE,0)
//SYSPRINT DD SYSOUT=*
//SYSUT1 DD DSN=SUBMIT.LIBRARY(JOB2),DISP=SHR
//SYSUT2 DD SYSOUT=(*,INTRDR)
//SYSIN DD DUMMY
//ERRMSG EXEC PGM=SHOWERR,COND=(VALIDATE,EQ,0),
// PARM='Error in PAYROLL Job'
Post by Andrew Rowley
Post by Hobart Spitz
Basically, JCL is so far from real a programming language, that I can't
describe it.
That's because JCL isn't a programming language. There are plenty of
other languages that also suck as programming languages e.g. HTML,
XML, JSON, but that's not what they are supposed to be.
JCL is really a kind of definition language. In programming language
terms it is more like a set of classes in OOP than a language in
itself: you have a job, which has steps, steps have DDs etc. The
syntax is old fashioned, but the concepts are very much OOP. It would
be relatively simple to create a set of classes in your OOP language
of choice to hide the syntax - just create a Job object, add Step
objects, add DataDefinition objects etc. and have a Submit method emit
JCL.
If I want to write a program, I will choose a programming language. If
I want to define a unit of work to the system, JCL does a pretty good
job. I definitely prefer JCL to long command lines with multiple
switches and options defining input and output files, which is the
non-z/OS equivalent.
Andrew Rowley
Black Hill Software
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **| *

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Joel C. Ewing
2018-07-04 16:21:37 UTC
Permalink
Raw Message
Post by Ward Able, Grant
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-----
Sent: 03 July 2018 21:39
Subject: Re: REXX as JCL replacement
ATTENTION! This email originated outside of DTCC; exercise caution.
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
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 ***@acm.org

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-04 16:53:08 UTC
Permalink
Raw Message
or someone would produced an alternative by now
Not touting it -- I know nada about it, nor am I on the front lines of dealing with production JCL -- but someone has, right? That JOL product that pops up here from time to time. https://sites.google.com/site/clarkecomputersoftware/oscar_jol_desc-html

Not a very encouraging Web site. I can't get the manuals to open (Chrome).

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing
Sent: Wednesday, July 4, 2018 9:21 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clem Clarke
2018-07-05 00:55:35 UTC
Permalink
Raw Message
Thank you Charles.

I think you will find this site has much more information.
http://start.oscar-jol.com/

And indeed, it was a language written specifically to replace JCL and
was used by some of the largest companies in the world for decades.

The JCL problem is basically unchanged after decades. Jol is an answer.
People liked it, and they could do much more than with standard JCL.
It's syntax is PL/I ish, or similar to Rexx, but the statements are
designed for allocating data sets and running programs and jobs, along
with full arithmetic expressions for examining and altering Symbolic
Variables.

Furthermore, Jol can execute programs by creating optimized JCL, or by
using Dynamic Allocation, which means that the same job can be executed
in Batch or under TSO, unchanged.

What would it take for IBM to allocate just a couple of people to make
it available as a supported product?

Clem Clarke
Post by Charles Mills
or someone would produced an alternative by now
Not touting it -- I know nada about it, nor am I on the front lines of dealing with production JCL -- but someone has, right? That JOL product that pops up here from time to time. https://sites.google.com/site/clarkecomputersoftware/oscar_jol_desc-html
Not a very encouraging Web site. I can't get the manuals to open (Chrome).
Charles
-----Original Message-----
Sent: Wednesday, July 4, 2018 9:21 AM
Subject: Re: REXX as JCL replacement
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-07-05 01:14:42 UTC
Permalink
Raw Message
Post by Clem Clarke
What would it take for IBM to allocate just a couple of people to make it
available as a supported product?
Having someone left in POK who knows how to code. Not sure there's anyone
left...

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-05 18:23:46 UTC
Permalink
Raw Message
I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX. That way, you
don't have to reinvent or do without all the things that REXX brings to the
table, both as a language and as something that interfaces with many parts
of z/OS. I.e., DB2, JES, ISPF, TSO, etc.

I think CA also has a similar product. I don't know anything about it, or
if it is used much.

The existence of JOL and the CA product suggest that there is a wider need
than realized to upgrade z/OS batch processing to more modern methods.
Historically, IBM has had more scripting languages than platforms (z/OS:
REXX, CLIST, JCL. z/VM: EXEC, EXEC2, REXX. AS/400: OCL.), and z/OS is the
only major platform where the batch scripting language (JCL) can't run in
foreground, and the foreground scripting languages can be useful in
background, but aren't. z/VM has never had a separate batch scripting
language, and it still can do things that z/OS was never designed for.

I think Ward's question was well answered. I might add a few things later
that were missed. (I have a long draft that is mostly redundant.)

All that said, I'd like to come back to the primary, perhaps only, reason
why REXX is not used more in batch: "Parallel ENQs", or the lack thereof.
I use quotation marks because I am skeptical that anything like this can
actually be truly simultaneous. On the other hand, the time scale on which
ENQs are typically held means that near simultaneous is fast enough.

BTW, if all updatable application data is stored in DB2 tables (e.g.)
and/or all DISPs are SHR, there is no reason not to use REXX in batch. If
DISP=OLD is never used there can be no deadly embrace. This is not
theory. In the early 1990s, I did just such a project, replacing more than
300 JOB streams with less than 10 much smarter ones that began by invoking
a REXX program. All updated data was in DB2, and we used a REXX-to-DB2
interface.

Let's consider what a "Parallel ENQ" routine might look like. This should
allow the approach to be explored and refined, proving/disproving the
concept to site management and vendors, and help formulate the most
appropriate RFE.

Here a first draft, untested, for an external, preferably compiled routine:


*AllocMlt:*

*/* REXX - Allocate dataset(s) to files(s). Retry and recover if needed.
*/*

*/* Arg syntax: DDName BeforeDisp[","NormDisp] Dataset... [")" options]
*/*

*/* Abnormal Disp to be handled by return code check and FREE in caller.
*/*

*/* We let ALLOC report problems with ENQs of concatenated datasets.
*/*

*/* Stop on the first failure; if we could send msgs. in fut., keep
going.*/ *



*Alloced. = 0 /* Track successes
*/*























*do iA = 1 to arg() until RC <> 0 parse upper value arg(iA) with DDName
Disp DSN /* Code RecFM, LRecL, DataClas, Space, etc. after DSN and ")".
*/ /* ALLOC allows concatenation via a list of dataset names.
*/ /* DSN may be a list if Disp not NEW or MOD. */ parse var
Disp BeforeDisp "," NormDisp /* Like JCL. */ Status = sysdsn(word(DSN,
1)) if BeforeDisp = "ASIS" then BeforeDisp = word("new old",
(Status = "OK") + 1) /* Allows skipping archaic use of IEFBR14. */
if wordpos(BeforeDisp, "OLD SHR") > 0 then do iTry = 1 to 5 while
Status = "DATASET UNAVAILABLE" say time() DSN "unavailable,
retrying." /* Would be important to send message to ENQ holder,
esp. TSU. */ call sleep "10 sec" /* SLEEP may need to be
written. */ Status = sysdsn(word(DSN, 1)) end iTry
select when Status = "OK" & wordpos(BeforeDisp, "OLD SHR") > 0
then nop when subword(Status, 2) = "NOT FOUND" & *
*wordpos(BeforeDisp, "NEW MOD") then*

















* nop otherwise /* Status incompatible with BeforeDisp,
or other error. */ say "Attempting" arg(iA)", status"
Status"." leave iA end "allocate reuse
file("DDname")" BeforeDisp NormDisp "dataset("DSN Alloced.iA = (RC = 0)
end iAif iA > arg() then /* Success */ exit 0/* Failure */do iA2 = 1
to iA if Alloced.iA2 "free file("word(arg(iA2), 1) end iAexit
-iA*



Any thoughts? Anyone want to try it out and post the results?

SYSDSN() having the relatively new DATASET UNAVAILABLE value means there
are other, possibly more creative ways to handle ENQ conflicts.



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.
Post by zMan
Post by Clem Clarke
Post by Clem Clarke
What would it take for IBM to allocate just a couple of people to make
it
Post by Clem Clarke
available as a supported product?
Having someone left in POK who knows how to code. Not sure there's anyone
left...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-05 20:29:11 UTC
Permalink
Raw Message
I have not really thought it through but I just cannot picture how building some combination of Rexx or whatever + assembler one could not do 'n' simultaneous ENQs. The facilities are there in MVS for the asking:

"ENQ assigns control of one or more serially reusable resources to a task. If any of
the resources are not available, the task might be placed in a wait condition until
all of the requested resources are available."

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz
Sent: Thursday, July 5, 2018 11:24 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX. That way, you
don't have to reinvent or do without all the things that REXX brings to the
table, both as a language and as something that interfaces with many parts
of z/OS. I.e., DB2, JES, ISPF, TSO, etc.

I think CA also has a similar product. I don't know anything about it, or
if it is used much.

The existence of JOL and the CA product suggest that there is a wider need
than realized to upgrade z/OS batch processing to more modern methods.
Historically, IBM has had more scripting languages than platforms (z/OS:
REXX, CLIST, JCL. z/VM: EXEC, EXEC2, REXX. AS/400: OCL.), and z/OS is the
only major platform where the batch scripting language (JCL) can't run in
foreground, and the foreground scripting languages can be useful in
background, but aren't. z/VM has never had a separate batch scripting
language, and it still can do things that z/OS was never designed for.

I think Ward's question was well answered. I might add a few things later
that were missed. (I have a long draft that is mostly redundant.)

All that said, I'd like to come back to the primary, perhaps only, reason
why REXX is not used more in batch: "Parallel ENQs", or the lack thereof.
I use quotation marks because I am skeptical that anything like this can
actually be truly simultaneous. On the other hand, the time scale on which
ENQs are typically held means that near simultaneous is fast enough.

BTW, if all updatable application data is stored in DB2 tables (e.g.)
and/or all DISPs are SHR, there is no reason not to use REXX in batch. If
DISP=OLD is never used there can be no deadly embrace. This is not
theory. In the early 1990s, I did just such a project, replacing more than
300 JOB streams with less than 10 much smarter ones that began by invoking
a REXX program. All updated data was in DB2, and we used a REXX-to-DB2
interface.

Let's consider what a "Parallel ENQ" routine might look like. This should
allow the approach to be explored and refined, proving/disproving the
concept to site management and vendors, and help formulate the most
appropriate RFE.

Here a first draft, untested, for an external, preferably compiled routine:


*AllocMlt:*

*/* REXX - Allocate dataset(s) to files(s). Retry and recover if needed.
*/*

*/* Arg syntax: DDName BeforeDisp[","NormDisp] Dataset... [")" options]
*/*

*/* Abnormal Disp to be handled by return code check and FREE in caller.
*/*

*/* We let ALLOC report problems with ENQs of concatenated datasets.
*/*

*/* Stop on the first failure; if we could send msgs. in fut., keep
going.*/ *



*Alloced. = 0 /* Track successes
*/*























*do iA = 1 to arg() until RC <> 0 parse upper value arg(iA) with DDName
Disp DSN /* Code RecFM, LRecL, DataClas, Space, etc. after DSN and ")".
*/ /* ALLOC allows concatenation via a list of dataset names.
*/ /* DSN may be a list if Disp not NEW or MOD. */ parse var
Disp BeforeDisp "," NormDisp /* Like JCL. */ Status = sysdsn(word(DSN,
1)) if BeforeDisp = "ASIS" then BeforeDisp = word("new old",
(Status = "OK") + 1) /* Allows skipping archaic use of IEFBR14. */
if wordpos(BeforeDisp, "OLD SHR") > 0 then do iTry = 1 to 5 while
Status = "DATASET UNAVAILABLE" say time() DSN "unavailable,
retrying." /* Would be important to send message to ENQ holder,
esp. TSU. */ call sleep "10 sec" /* SLEEP may need to be
written. */ Status = sysdsn(word(DSN, 1)) end iTry
select when Status = "OK" & wordpos(BeforeDisp, "OLD SHR") > 0
then nop when subword(Status, 2) = "NOT FOUND" & *
*wordpos(BeforeDisp, "NEW MOD") then*

















* nop otherwise /* Status incompatible with BeforeDisp,
or other error. */ say "Attempting" arg(iA)", status"
Status"." leave iA end "allocate reuse
file("DDname")" BeforeDisp NormDisp "dataset("DSN Alloced.iA = (RC = 0)
end iAif iA > arg() then /* Success */ exit 0/* Failure */do iA2 = 1
to iA if Alloced.iA2 "free file("word(arg(iA2), 1) end iAexit
-iA*



Any thoughts? Anyone want to try it out and post the results?

SYSDSN() having the relatively new DATASET UNAVAILABLE value means there
are other, possibly more creative ways to handle ENQ conflicts.



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.
Post by zMan
Post by Clem Clarke
Post by Clem Clarke
What would it take for IBM to allocate just a couple of people to make
it
Post by Clem Clarke
available as a supported product?
Having someone left in POK who knows how to code. Not sure there's anyone
left...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-06 15:02:09 UTC
Permalink
Raw Message
The issue is not doing simultaneous ENQs; the issue is getting Allocation to do them, correctly and in a safe fashion. The major names in question are protected, to say nothing of the need for the ENQ to be done against the Initiator TCB.

IBM could certainly provide such a service, but we're not talking about 50 or a 100 lines of code; it's not intractable, but neither is it trivial.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Charles Mills <***@MCN.ORG>
Sent: Thursday, July 5, 2018 4:29 PM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement

I have not really thought it through but I just cannot picture how building some combination of Rexx or whatever + assembler one could not do 'n' simultaneous ENQs. The facilities are there in MVS for the asking:

"ENQ assigns control of one or more serially reusable resources to a task. If any of
the resources are not available, the task might be placed in a wait condition until
all of the requested resources are available."

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz
Sent: Thursday, July 5, 2018 11:24 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement

I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX. That way, you
don't have to reinvent or do without all the things that REXX brings to the
table, both as a language and as something that interfaces with many parts
of z/OS. I.e., DB2, JES, ISPF, TSO, etc.

I think CA also has a similar product. I don't know anything about it, or
if it is used much.

The existence of JOL and the CA product suggest that there is a wider need
than realized to upgrade z/OS batch processing to more modern methods.
Historically, IBM has had more scripting languages than platforms (z/OS:
REXX, CLIST, JCL. z/VM: EXEC, EXEC2, REXX. AS/400: OCL.), and z/OS is the
only major platform where the batch scripting language (JCL) can't run in
foreground, and the foreground scripting languages can be useful in
background, but aren't. z/VM has never had a separate batch scripting
language, and it still can do things that z/OS was never designed for.

I think Ward's question was well answered. I might add a few things later
that were missed. (I have a long draft that is mostly redundant.)

All that said, I'd like to come back to the primary, perhaps only, reason
why REXX is not used more in batch: "Parallel ENQs", or the lack thereof.
I use quotation marks because I am skeptical that anything like this can
actually be truly simultaneous. On the other hand, the time scale on which
ENQs are typically held means that near simultaneous is fast enough.

BTW, if all updatable application data is stored in DB2 tables (e.g.)
and/or all DISPs are SHR, there is no reason not to use REXX in batch. If
DISP=OLD is never used there can be no deadly embrace. This is not
theory. In the early 1990s, I did just such a project, replacing more than
300 JOB streams with less than 10 much smarter ones that began by invoking
a REXX program. All updated data was in DB2, and we used a REXX-to-DB2
interface.

Let's consider what a "Parallel ENQ" routine might look like. This should
allow the approach to be explored and refined, proving/disproving the
concept to site management and vendors, and help formulate the most
appropriate RFE.

Here a first draft, untested, for an external, preferably compiled routine:


*AllocMlt:*

*/* REXX - Allocate dataset(s) to files(s). Retry and recover if needed.
*/*

*/* Arg syntax: DDName BeforeDisp[","NormDisp] Dataset... [")" options]
*/*

*/* Abnormal Disp to be handled by return code check and FREE in caller.
*/*

*/* We let ALLOC report problems with ENQs of concatenated datasets.
*/*

*/* Stop on the first failure; if we could send msgs. in fut., keep
going.*/ *



*Alloced. = 0 /* Track successes
*/*























*do iA = 1 to arg() until RC <> 0 parse upper value arg(iA) with DDName
Disp DSN /* Code RecFM, LRecL, DataClas, Space, etc. after DSN and ")".
*/ /* ALLOC allows concatenation via a list of dataset names.
*/ /* DSN may be a list if Disp not NEW or MOD. */ parse var
Disp BeforeDisp "," NormDisp /* Like JCL. */ Status = sysdsn(word(DSN,
1)) if BeforeDisp = "ASIS" then BeforeDisp = word("new old",
(Status = "OK") + 1) /* Allows skipping archaic use of IEFBR14. */
if wordpos(BeforeDisp, "OLD SHR") > 0 then do iTry = 1 to 5 while
Status = "DATASET UNAVAILABLE" say time() DSN "unavailable,
retrying." /* Would be important to send message to ENQ holder,
esp. TSU. */ call sleep "10 sec" /* SLEEP may need to be
written. */ Status = sysdsn(word(DSN, 1)) end iTry
select when Status = "OK" & wordpos(BeforeDisp, "OLD SHR") > 0
then nop when subword(Status, 2) = "NOT FOUND" & *
*wordpos(BeforeDisp, "NEW MOD") then*

















* nop otherwise /* Status incompatible with BeforeDisp,
or other error. */ say "Attempting" arg(iA)", status"
Status"." leave iA end "allocate reuse
file("DDname")" BeforeDisp NormDisp "dataset("DSN Alloced.iA = (RC = 0)
end iAif iA > arg() then /* Success */ exit 0/* Failure */do iA2 = 1
to iA if Alloced.iA2 "free file("word(arg(iA2), 1) end iAexit
-iA*



Any thoughts? Anyone want to try it out and post the results?

SYSDSN() having the relatively new DATASET UNAVAILABLE value means there
are other, possibly more creative ways to handle ENQ conflicts.



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.
Post by zMan
Post by Clem Clarke
Post by Clem Clarke
What would it take for IBM to allocate just a couple of people to make
it
Post by Clem Clarke
available as a supported product?
Having someone left in POK who knows how to code. Not sure there's anyone
left...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clem Clarke
2018-07-10 23:20:07 UTC
Permalink
Raw Message
Don't know about that! I always think that IBM has some of the best
people and concepts.  Pity IBM didn't push PL/I instead od allowing C to
rule the world.

However, there's an interesting IBM lab in Perth that has some excellent
people. Not many people know about it.

I worked there for a few years. Loved it.

Clem
Post by zMan
Post by Clem Clarke
What would it take for IBM to allocate just a couple of people to make it
available as a supported product?
Having someone left in POK who knows how to code. Not sure there's anyone
left...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
David Crayford
2018-07-11 10:40:52 UTC
Permalink
Raw Message
Post by Clem Clarke
Don't know about that! I always think that IBM has some of the best
people and concepts.  Pity IBM didn't push PL/I instead od allowing C
to rule the world.
They did, but something that's free will always be more attractive.
Multics was originally written in PL/I but the UNIX devs didn't think it
was suitable for operating systems.
Post by Clem Clarke
However, there's an interesting IBM lab in Perth that has some
excellent people. Not many people know about it.
Not any more! They all got the push when IBM recently cut their
workforce. A few of them moved to HCL with the PD products. The rest of
them are looking for work.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Hobart Spitz
2018-07-11 12:37:24 UTC
Permalink
Raw Message
The JOL effort is commendable, but replacing JCL is about much more than a
nicer syntax or easy movement between foreground and background.

At the risk of repetition, other reasons are (1) to eliminate the
separation between scripting code and application code and (2) to interface
with other software/data (files, DB2, ISPF, etc.).

Resistance to replacing JCL comes from the fact that "everybody knows JCL"
(which they don't really). Everybody (in the target audience) knows REXX,
if not directly, then because REXX has many well-know features of other
languages. JCL resembles only mainframe assembler.

Add in PIPElines and you get a productivity and performance improvements
unlike any other option available. Charles's example in REXX and PIPElines
might look like this.

1. "pipe (end ?) ? < trans | v: validate | g: gate",
2. "? v: sort 10.10 | g:| u: update | >" GDG("payroll.master(+1)")",
3. "? <" GDG("payroll.master(0)") | u:"
4.
5. if RC = 0 then
6. "submit job2"
7. else
8. "delete" GDG("payroll.master(0)")

I tried to stay true to Charles's example. If you can to skip invalid
transactions, but still process valid ones (a reasonable approach), you can
eliminate the GATE and combine the first two streams.

GDG() is a function that I've previously written.

Note that zero intermediate files are needed, saving those I/O operations.

I haven't read the details of JOL, so I might be missing something. I'm
happy to be educated.


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.
Post by David Crayford
Post by Clem Clarke
Don't know about that! I always think that IBM has some of the best
people and concepts. Pity IBM didn't push PL/I instead od allowing C to
rule the world.
They did, but something that's free will always be more attractive.
Multics was originally written in PL/I but the UNIX devs didn't think it
was suitable for operating systems.
However, there's an interesting IBM lab in Perth that has some excellent
Post by Clem Clarke
people. Not many people know about it.
Not any more! They all got the push when IBM recently cut their workforce.
A few of them moved to HCL with the PD products. The rest of them are
looking for work.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
zMan
2018-07-11 14:47:28 UTC
Permalink
Raw Message
Post by Clem Clarke
However, there's an interesting IBM lab in Perth that has some excellent
Post by Clem Clarke
people. Not many people know about it.
Not any more! They all got the push when IBM recently cut their workforce.
A few of them moved to HCL with the PD products. The rest of them are
looking for work.
I'm afraid that when I read Clem's statement, my immediate thought was,
"You probably mean 'WAS an interesting IBM lab...'". Sorry to hear that I
was correct.

IBM really seems to be in a death-spiral. Very sad.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-04 17:39:27 UTC
Permalink
Raw Message
On 4 Jul 2018 09:21:37 -0700, ***@ACM.ORG (Joel C. Ewing) wrote:

As someone who was enraged by MVS JCL on more than one occasion, I
believe a fruitful area of study would be to look at how Burroughs
then successor Unisys handled the problem on the B5000 and successors,
Univac then successor Unisys handled it on the 2200 series and
successors and IBM on the AS400 and i successors. I have read good
things about both the B5000 etc. and AS400 facilities.

Clark Morris
Post by Joel C. Ewing
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
Paul Gilmartin
2018-07-04 17:00:51 UTC
Permalink
Raw Message
Post by Joel C. Ewing
Post by Ward Able, Grant
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.)
Post by Joel C. Ewing
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 ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jack J. Woehr
2018-07-04 18:56:18 UTC
Permalink
Raw Message
Post by Paul Gilmartin
JCL has numerous restrictions and inconsistencies due to antiquity,
IBM i supports Cobol. Come on down :)
--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
www.well.com/~jax # thinking, a way of skeptically interrogating the universe
www.softwoehr.com # with a fine understanding of human fallibility. - Carl Sagan

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-07-05 13:07:39 UTC
Permalink
Raw Message
Post by Jack J. Woehr
Post by Paul Gilmartin
JCL has numerous restrictions and inconsistencies due to antiquity,
IBM i supports Cobol. Come on down :)
​A few years ago, the IBMi was under consideration to replace our, very
old, IBMz. I got some documentation on it. I was _extremely_ impressed.
Now, for a "hard coded" system _programmer_, it is death. Because there
simply is not much to do. Basically apply maintenance and parameters. No
real programming, except perhaps some type of utility. ILE COBOL looks
good. Well, as good as any COBOL looks to me {grin}. I love the fact that
the basic filesystem is really a relational database. So you can not only
access it as if it were a "keyed" file (like VSAM KSDS) but also as SQL
database like DB2. ​They also have PACE, which is the "POSIX compliant"
portion, which is "hooked onto" the IBMi like "Unix System Services" is
"hooked onto" the historic z/OS system. There is an email group for it too.
The people there are also fantastically helpful. I posted that we were
looking into the IBMi and one person sent me about 5 books on it -- at HIS
expense! I was "knocked on my butt".
Post by Jack J. Woehr
--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-05 13:40:45 UTC
Permalink
Raw Message
Many moons ago we ported a product from z/OS to the AS/400 and were similarly impressed with the sorts of things you mention. The OS was solid as a rock.

There is a major learning curve -- the darned thing is unlike any other computer. And many APIs are locked up and not available without some special license or fee. For example, in every other operating system I have used, a program can open an executable file (.exe, load module, etc.) as a normal file and read it -- typically just like any other file, if that makes sense in the particular situation. Not so in OS/400. Also as I recall a lot of services were only available via panels -- like if ISPF were the *only* way to accomplish certain z/OS tasks.

It was a somewhat tough port for the reasons described.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: Thursday, July 5, 2018 6:07 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: IBM i as JCL replacement (was: Rexx as JCL replacement)
Post by Jack J. Woehr
Post by Paul Gilmartin
JCL has numerous restrictions and inconsistencies due to antiquity,
IBM i supports Cobol. Come on down :)
​A few years ago, the IBMi was under consideration to replace our, very
old, IBMz. I got some documentation on it. I was _extremely_ impressed.
Now, for a "hard coded" system _programmer_, it is death. Because there
simply is not much to do. Basically apply maintenance and parameters. No
real programming, except perhaps some type of utility. ILE COBOL looks
good. Well, as good as any COBOL looks to me {grin}. I love the fact that
the basic filesystem is really a relational database. So you can not only
access it as if it were a "keyed" file (like VSAM KSDS) but also as SQL
database like DB2. ​They also have PACE, which is the "POSIX compliant"
portion, which is "hooked onto" the IBMi like "Unix System Services" is
"hooked onto" the historic z/OS system. There is an email group for it too.
The people there are also fantastically helpful. I posted that we were
looking into the IBMi and one person sent me about 5 books on it -- at HIS
expense! I was "knocked on my butt".
Post by Jack J. Woehr
--
Jack J. Woehr # Science is more than a body of knowledge. It's a way of
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-07-05 14:47:19 UTC
Permalink
Raw Message
I spend more time now days supporting a handful of IBM i LPARs than our z/OS systems. There are definitely some frustrating facets of the IBM i world. For instance, the 5250 emulation is almost all 24x80, with just a few panels that actually utilize 27x132, and thats it! Many new functions are implemented in the web interface only but not all, so you still need to use them both.

Dana
Post by John McKown
​A few years ago, the IBMi was under consideration to replace our, very
old, IBMz. I got some documentation on it. I was _extremely_ impressed.
Now, for a "hard coded" system _programmer_, it is death. Because there
simply is not much to do.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-07-05 14:51:29 UTC
Permalink
Raw Message
Post by Dana Mitchell
I spend more time now days supporting a handful of IBM i LPARs than our
z/OS systems. There are definitely some frustrating facets of the IBM i
world. For instance, the 5250 emulation is almost all 24x80, with just
a few panels that actually utilize 27x132, and thats it! Many new
functions are implemented in the web interface only but not all, so you
still need to use them both.
​Well. There is nothing quite so sobering as the voice of experience!​
Post by Dana Mitchell
Dana
On Thu, 5 Jul 2018 08:07:18 -0500, John McKown <
Post by John McKown
​A few years ago, the IBMi was under consideration to replace our, very
old, IBMz. I got some documentation on it. I was _extremely_ impressed.
Now, for a "hard coded" system _programmer_, it is death. Because there
simply is not much to do.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-05 19:38:23 UTC
Permalink
Raw Message
[Default] On 5 Jul 2018 07:47:19 -0700, in bit.listserv.ibm-main
Post by Dana Mitchell
I spend more time now days supporting a handful of IBM i LPARs than our z/OS systems. There are definitely some frustrating facets of the IBM i world. For instance, the 5250 emulation is almost all 24x80, with just a few panels that actually utilize 27x132, and thats it! Many new functions are implemented in the web interface only but not all, so you still need to use them both.
For batch processes how does the i series command language compare to
JCL. How are competing requests for file access handled?

Clark Morris
Post by Dana Mitchell
Dana
?A few years ago, the IBMi was under consideration to replace our, very
old, IBMz. I got some documentation on it. I was _extremely_ impressed.
Now, for a "hard coded" system _programmer_, it is death. Because there
simply is not much to do.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-05 19:24:57 UTC
Permalink
Raw Message
Post by Hobart Spitz
I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX.
I wonder how JOL addresses theneed for "parallel ENQs". S99WTDSN requires
APF authorization. Does JOL submit "optimized" JCL, or is it authorized so it
can do all the initiator does to run a mix of authorized and unauthorized steps.
Post by Hobart Spitz
The existence of JOL and the CA product suggest that there is a wider need
than realized to upgrade z/OS batch processing to more modern methods.
REXX, CLIST, JCL. z/VM: EXEC, EXEC2, REXX. AS/400: OCL.), and z/OS is the
only major platform where the batch scripting language (JCL) can't run in
foreground, ...
Why would one want to?
Post by Hobart Spitz
... and the foreground scripting languages can be useful in
background, but aren't. ...
There's IRXJCL and IKJEFT*.
Post by Hobart Spitz
... z/VM has never had a separate batch scripting
language, and it still can do things that z/OS was never designed for.
UNIX has never had a separate batch scripting language.
Post by Hobart Spitz
All that said, I'd like to come back to the primary, perhaps only, reason
why REXX is not used more in batch: "Parallel ENQs", or the lack thereof.
I use quotation marks because I am skeptical that anything like this can
actually be truly simultaneous. On the other hand, the time scale on which
ENQs are typically held means that near simultaneous is fast enough.
I'm confident that ENQ serializes all affected systems so the action of any
single ENQ call appears instantanteous to the caller and to all other jobs on
any systems.
Post by Hobart Spitz
Let's consider what a "Parallel ENQ" routine might look like. This should
allow the approach to be explored and refined, proving/disproving the
concept to site management and vendors, and help formulate the most
appropriate RFE.
*AllocMlt:*
*/* REXX - Allocate dataset(s) to files(s). Retry and recover if needed.
*/*
The "retry and recover" must FREE all resources held and start ab ovo
in order to avoid deadlocks. And that might lead to unacceptable thrashing.

(Most of your sample code was flowed illegibly. How'd you do that?)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clem Clarke
2018-07-11 00:12:19 UTC
Permalink
Raw Message
Post by Paul Gilmartin
Post by Hobart Spitz
I think a more encompassing approach would be for JOL to be a function,
command or environment which could be invoked from REXX.
JOL could be invoked from REXX. Or JCL.
When the JOL *compiler* is invoked from TSO though, the Panels and other
functions can be used to interact with the user, and suggested by the
main screen shown at www.Oscar-Jol.com

The job can then be submitted to batch to run, or executed under TSO.
Post by Paul Gilmartin
I wonder how JOL addresses theneed for "parallel ENQs". S99WTDSN requires
APF authorization. Does JOL submit "optimized" JCL, or is it authorized so it
can do all the initiator does to run a mix of authorized and unauthorized steps.
Jol executes user programs in two main ways.

1. Jol can produce JCL which is run under the control of a "monitor"
program that catalogs data sets and runs programs underneath it.

2. It can use Dynamic Allocation and effectively replace the Initiator.
    a) When the job is to be executed under TSO, no JCL is produced at all.
    b) When submitted to batch, it produces some JCL to invoke the Jol
monitor, which does all the data set allocation and executes the problem
program.
Post by Paul Gilmartin
... text deleted
UNIX has never had a separate batch scripting language.
There is a alpha test version of Jol that does run under Linux and
execute user programs, much like Z/OS batch.

That version of Jol is written in "C" and can produce Z/OS JCL, or run
Windows or Linux programs. It could be ported to Z/OS.

It also can produce VSE code, although it is in testing mode only.

Clem

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-05 20:00:33 UTC
Permalink
Raw Message
Post by Clark Morris
For batch processes how does the i series command language compare to
JCL. How are competing requests for file access handled?
If, as John says, the filesystem paradigm is a relational data base, there's
very little comparison. There should be Logical Unit of Work isolation.
Conflicts can occur; the perpetrator has no choice but to ROLLBACK while
someone else COMMITs.

That's what I remember from some minor use of CMS SQL/DS, the country
cousin of DB2. How does DB2 handle competing updates?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-07-05 20:08:09 UTC
Permalink
Raw Message
Most everything is menu driven, about the closest thing on IBM i are CL programs (Control Language). Think Clists but they require compilation. An optional IBM licensed program product, Advanced Job Scheduler, has a way to schedule a series of commands, but there is no conditional processing capability. ISV products may provide more function, but I have no experience with anything other than IBM AJS.
Post by Clark Morris
For batch processes how does the i series command language compare to
JCL.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-05 21:47:52 UTC
Permalink
Raw Message
Post by Charles Mills
"ENQ assigns control of one or more serially reusable resources to a task. If any of
the resources are not available, the task might be placed in a wait condition until
all of the requested resources are available."
From: z/OS IBM MVS Programming: Authorized Assembler Services Guide
Version 2 Release 3 SA23-1371-30
Chapter 25. Dynamic allocation
Requesting a data set that is in use:
Rather than wait for another user to release a data set, volume, or device to
obtain use of it, dynamic allocation fails a request by an unauthorized program.
If an authorized program specifically requests a wait, dynamic allocation will wait.

The designers were dedicated and capable. There's no way to wait for a dynamically
allocated resource without introducing the hazard of a deadlock.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-05 22:35:29 UTC
Permalink
Raw Message
Right. And I don't believe "JCL" does. I think think the scheduling component of JESx or something similar either waits or polls.

Anyway, you are reading about SVC 99. I meant a separate module to do the ENQs. I would guess that SVC 99 does a RET=HAVE so there would be no harm in a pre-ENQ.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, July 5, 2018 2:48 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Post by Charles Mills
"ENQ assigns control of one or more serially reusable resources to a task. If any of
the resources are not available, the task might be placed in a wait condition until
all of the requested resources are available."
From: z/OS IBM MVS Programming: Authorized Assembler Services Guide
Version 2 Release 3 SA23-1371-30
Chapter 25. Dynamic allocation
Requesting a data set that is in use:
Rather than wait for another user to release a data set, volume, or device to
obtain use of it, dynamic allocation fails a request by an unauthorized program.
If an authorized program specifically requests a wait, dynamic allocation will wait.

The designers were dedicated and capable. There's no way to wait for a dynamically
allocated resource without introducing the hazard of a deadlock.

-- gil

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-06 14:46:32 UTC
Permalink
Raw Message
MDS in JES3 handles some waiting, but that doesn't apply to JES2 and IAC the Initiator will still do the ENQ.

Be careful what you ask for; you might get it. A separate module to do the ENQ might not behave in a fashion that you like.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Charles Mills <***@MCN.ORG>
Sent: Thursday, July 5, 2018 6:35 PM
To: IBM-***@listserv.ua.edu
Subject: Re: REXX as JCL replacement

Right. And I don't believe "JCL" does. I think think the scheduling component of JESx or something similar either waits or polls.

Anyway, you are reading about SVC 99. I meant a separate module to do the ENQs. I would guess that SVC 99 does a RET=HAVE so there would be no harm in a pre-ENQ.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: Thursday, July 5, 2018 2:48 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Post by Charles Mills
"ENQ assigns control of one or more serially reusable resources to a task. If any of
the resources are not available, the task might be placed in a wait condition until
all of the requested resources are available."
From: z/OS IBM MVS Programming: Authorized Assembler Services Guide
Version 2 Release 3 SA23-1371-30
Chapter 25. Dynamic allocation
Requesting a data set that is in use:
Rather than wait for another user to release a data set, volume, or device to
obtain use of it, dynamic allocation fails a request by an unauthorized program.
If an authorized program specifically requests a wait, dynamic allocation will wait.

The designers were dedicated and capable. There's no way to wait for a dynamically
allocated resource without introducing the hazard of a deadlock.

-- gil

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

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jantje.
2018-07-06 10:40:31 UTC
Permalink
Raw Message
Post by Charles Mills
Many moons ago we ported a product from z/OS to the AS/400 and were similarly impressed with the sorts of things you mention. The OS was solid as a rock.
Hear, hear !
Post by Charles Mills
There is a major learning curve
Having gone down that path, I have to contradict this statement. OK, granted, there are a few quirks one has to get used to, but the fact that the whole system, from the hardest "real system-programmer" stuff to the development, to the end user is really consistent in the way things behave and are presented, makes it IMHO easy to grasp.
Post by Charles Mills
-- the darned thing is unlike any other computer.
That is true.
Post by Charles Mills
Also as I recall a lot of services were only available via panels -- like if ISPF were the *only* way to accomplish certain z/OS tasks.
This is no longer true. In the recent versions of the OS, there are numerous API's available to call from CL, COBOL, C, even Java, that do almost everything and anything.


Cheers,

Jantje.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jantje.
2018-07-06 10:45:29 UTC
Permalink
Raw Message
Post by Clark Morris
For batch processes how does the i series command language compare to
JCL.
One typically uses CL to program ones batch jobs. And when I say 'program' that is exactly what I mean. CL is a very complete programming language. It really does not compare to JCL on mainframe; it is way more powerful.
Post by Clark Morris
How are competing requests for file access handled?
Depends on how you set up commitment control for your job. From 'not-at-all' to full-blown 2-phase commit; just tell the system what you need for that particular job.


Cheers,

Jantje.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jantje.
2018-07-06 10:49:54 UTC
Permalink
Raw Message
Post by Dana Mitchell
Most everything is menu driven,
Indeed it is, but hitting PF14 on that menu will show you the equivalent CL command with all the options you just filled in in the right place and with the correct syntax. Just cut&paste that into your CL source... or onto your command line for that matter.


Cheers,

Jantje.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clem Clarke
2018-07-11 00:18:00 UTC
Permalink
Raw Message
Jol has a comprehensive menu system too.

Or it can be used with a PL/I type English like script.

For example,

    Testjob: job;
    Print Sys1.Maclib(call);

Clem
Post by Jantje.
Post by Dana Mitchell
Most everything is menu driven,
Indeed it is, but hitting PF14 on that menu will show you the equivalent CL command with all the options you just filled in in the right place and with the correct syntax. Just cut&paste that into your CL source... or onto your command line for that matter.
Cheers,
Jantje.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-09 14:15:01 UTC
Permalink
Raw Message
Post by Hobart Spitz
I think that it's important to first understand the characteristics on
which many people base their thinking that JCL is good and may never go
away. The point is important, and the basis is a valid concern. The
conclusion is wrong. All it takes is understanding the problem and coming
up with creative solutions. As I describe below, DB2 based applications
and those that use only PDSEs are likely to be good starting points.
ISPF provides an alternative ENQ mechanism for both Classic PDS and PDSE,
successfully assuming that EXC ENQs will be transitory. OTOH, LMPUT
requires EXC ENQ, needlessly for PDSE members.
Post by Hobart Spitz
One valuable feature of z/OS batch processing is that all ENQs for the
entire JOB are obtained before any step execution actually starts. This is
done to prevent a deadly embrace: JOB A has exclusive access to dataset X
and needs exclusive access to dataset Y. JOB B has access to Y and needs
exclusive on X. Neither JOB can proceed until one is canceled, resulting
in lost production. Despite this being a useful service, there is no TSO
equivalent, either via a parallel ENQs (as Seymour suggested) or a standard
SLEEP mechanism to allow for retries.
Unless there's a time limit or loop count limit, this results in similar deadlocks.
Post by Hobart Spitz
...
When a batch JOB becomes eligible for execution these actions, relevant to
1. SETs are processed, and EXECed PROCs, overrides, and INCLUDEs are
merged with the submitted JCL. These are necessary for #2 below.
2. Substitutions are processed. This is needed for #3; if DSNs could
change later, via substitution or IF, the ENQs would be incorrect.
Data set aliases break this assumption.
Post by Hobart Spitz
3. ENQs are obtained on all datasets.
But for ALIAS names, not RELATED names.
Post by Hobart Spitz
4. The EXECs for PGMs are processed, in order, one at a time.
At this point an ENQ for the RELATED name is attempted. There is no
recovery from ENQ failure.
Post by Hobart Spitz
So any REXX implementation would have either to forgo do initial ENQs, or
commit to not changing DSNs during processing, or observe certain
conventions. These conventions could include the following, one or the
- Perform ENQs in a consistent order. (Left as an exercise for the
reader. :-) )
However effective this is, I doubt that it's practical. I suspect you feel likewise.
Post by Hobart Spitz
- Do all ALLOCations up front, and free all exclusive allocations before
a second set of ENQs is requested.
"exclusive" doesn't suffice. Imagine that JOB A has shared access to
dataset X and needs exclusive access to dataset Y. JOB B has shared
access to Y and needs exclusive on X. Deadlock occurs.
Post by Hobart Spitz
- Judiciously test for SYSDSN() returning the value UNAVAILABLE DATASET
or ALLOC failure, and taking appropriate action to recover/restart/suspend
processing. Initial ENQs are not required. If implemented via a common
routine, either site or vendor provided, this could be more viable. A
little additional coding to support automated restart might be needed; ...
??? SMOP?
Post by Hobart Spitz
- Something else.
??? Another exercise for the reader?
Post by Hobart Spitz
...
3. The JCL syntax (which is based on that of assembler AFAIK, a highly
inappropriate choice) is obscure, unintuitive, irregular, ...
Many Assembler facilities were created diachronically with insufficient
design consideration. Consider the difference in semantics between
macro arguments and SETC arguments.
Post by Hobart Spitz
... and has a steep learning curve.
ITYM "shallow" learning curve. Proficiency is acquired slowly.
Post by Hobart Spitz
4. JCL is a barrier to attracting new business to z/OS. Bad news if you
are a vendor.
Yes.
Post by Hobart Spitz
6. PROC EXECs, SETs, INCLUDEs cannot be conditional. Initial ENQs
prevent this. z/OS must know all dataset names to do the ENQs.
7. You can not loop or retry, as was done in the application I described
above.
8. You can't compare strings, do arithmetic, or employ complex logic.
9. You can't call a function or return a string value.
Should JCL assimilate HLASM's conditional assembly facility?
Post by Hobart Spitz
10. String/SET/PROC value substitution can convoluted. Do I need a
double period and/or a double ampersand? If you are passing a value down
two PROC level, you may have to put in 4 (!) ampersands or quotes to
indicate 1. More than two levels? Good luck!! REXX has no such
requirement.
Much of this could be resolved by adding HLASM's DOUBLE BIF to JCL.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-09 19:54:20 UTC
Permalink
Raw Message
Steve, thanks for the kind words.
One afterthought that might improve the use of the TSO PROC, if one is so
inclined. Use // EXEC TSO,CMD=REXXTRY , Put REXXTRY into one of the
SYSEXEC/SYSPROC libraries, if it's not already there. It gives access to
most of REXX to the SYSTSPRT records. REXXTRY is roughly to REXX what csh
is to C.
Not really. And you stated the restrictions yourself. And IBM wisely originally
implemented the POSIX shell, only later caving to pressure from (t)csh partisans.
1. *//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
2. *// JCLLIB ORDER=(MY.JCL.LIB) Optional*
3. *// EXEC TSO,CMD=REXXTRY*
....
That's more cumbersome than than just submitting an old-fashioned IEBGENER job.

The problem isn't JCL; it's OS.

I don't see that you allocated SYSPRINT.

Try doing the same with UNIX files and OMVS. It's easier.
... On the other hand, you
don't have multil-line commands, continuations, the ability to supply
internal routines or SIGNAL handlers, ...
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-10 00:56:40 UTC
Permalink
Raw Message
I wrote a product that as part of its processing generated JCL. (It was a side chore; it was not a "JCL-generator.") ...
I've done that a lot. I like to keep JCL embedded in POSIX shell scripts as here-documents.

o Not Rexx, first because Rexx has no instream data facility.

o I can use shell looping to generate multiple similar job steps. I might
do somewhat the same with PROC calls, but I think shell source is more
compact than JCL. And finer granularity: I can write a shell function
that generates a single DD statement -- not so with a JCL proc.

o I can substitute shell variables in JCL commands and JES instream data alike.
I started doing this before SET and DD *,SYMBOLS existed. It still works well.

o Like Rexx it's free of the apostrophe catastrophe. Metacharacters arising
from symbol expansion have no metasignificance -- they become ordinary
text with no need to escape, protect, or double them.
Ed Jaffe posted a video... it seems he worked some magic on it so that it's
only an excerpt from a longer presentation. It runs about 5 minutes, and
it's well worth that. Frederick P. Brooks had many talents, one of which
is he's an engaging and funny speaker.
The upshot (for our purposes) of his talk was that while they had a lot of
smart people designing some smart languages, JCL somehow appeared without
ever being planned or designed.
I see much the same about HLASM. It has a woeful lack of lexical uniformity.
...He *emphatically* states it's "the worst
language ever created, for any purpose, ever". Twice, if I counted
correctly.
Learning JCL is like learning Sheephead... at some point, you start to
think people are just making sh*t up as they go along. Come to think of
it, I think they probably did.
https://en.wikipedia.org/wiki/Sheepshead_(game)
??? Calvinball?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-07-10 12:37:28 UTC
Permalink
Raw Message
My memories of VSE JCL are dated, and quite possbily incorrect with current VSE, but I recall that I felt it was more complicated that MVS jcl. It had more types of statements (although fewer parms per type), JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To describe a disk file, potentially required at least 3 statements, ASSIGN, DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline files were not interchangeable as far as programs were concerned.

An interesting 'feature' was that syntax checking was done at execution time, so when a JCL error was encountered, a console message was issued that required a reply, allowing you to retype the errant statement. So in the days of real card readers, if you needed to make a quick one time change to a job, you could just flip the card around backwards, causing 'Invalid Statement' console message prompt, allowing you to type in the statement you really wanted.

Dana
How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL probably are
irrelevant.
Clark Morris
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
ITschak Mugzach
2018-07-10 12:46:56 UTC
Permalink
Raw Message
... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).

ITschak
Post by Dana Mitchell
My memories of VSE JCL are dated, and quite possbily incorrect with
current VSE, but I recall that I felt it was more complicated that MVS
jcl. It had more types of statements (although fewer parms per type),
JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To
describe a disk file, potentially required at least 3 statements, ASSIGN,
DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline
files were not interchangeable as far as programs were concerned.
An interesting 'feature' was that syntax checking was done at execution
time, so when a JCL error was encountered, a console message was issued
that required a reply, allowing you to retype the errant statement. So in
the days of real card readers, if you needed to make a quick one time
change to a job, you could just flip the card around backwards, causing
'Invalid Statement' console message prompt, allowing you to type in the
statement you really wanted.
Dana
How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL
probably are
irrelevant.
Clark Morris
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Contiguous Monitoring
for Legacy **| *

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-10 13:16:08 UTC
Permalink
Raw Message
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.

z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there are many things in z/VSE that I miss in z/OS. There
are also some things in z/OS that are not in z/VSE, but the last z/VSE
to z/OS conversion I did, the client programmers hated the 'limitations'
they found in z/OS and had to go do a lot of program changes due to
these limits.

Later, when I have time, I will list some of those things.

Tony Thigpen
Post by ITschak Mugzach
... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).
ITschak
Post by Dana Mitchell
My memories of VSE JCL are dated, and quite possbily incorrect with
current VSE, but I recall that I felt it was more complicated that MVS
jcl. It had more types of statements (although fewer parms per type),
JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To
describe a disk file, potentially required at least 3 statements, ASSIGN,
DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline
files were not interchangeable as far as programs were concerned.
An interesting 'feature' was that syntax checking was done at execution
time, so when a JCL error was encountered, a console message was issued
that required a reply, allowing you to retype the errant statement. So in
the days of real card readers, if you needed to make a quick one time
change to a job, you could just flip the card around backwards, causing
'Invalid Statement' console message prompt, allowing you to type in the
statement you really wanted.
Dana
How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL
probably are
irrelevant.
Clark Morris
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-07-10 13:23:22 UTC
Permalink
Raw Message
Post by Tony Thigpen
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.
​OS/360 -- either MFT or MVT.​
Post by Tony Thigpen
z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there are many things in z/VSE that I miss in z/OS. There
are also some things in z/OS that are not in z/VSE, but the last z/VSE
to z/OS conversion I did, the client programmers hated the 'limitations'
they found in z/OS and had to go do a lot of program changes due to
these limits.
Later, when I have time, I will list some of those things.
​I think that would be very interesting. I am eagerly awaiting.​
Post by Tony Thigpen
Tony Thigpen
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-10 14:08:00 UTC
Permalink
Raw Message
Post by Tony Thigpen
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.
z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there are many things in z/VSE that I miss in z/OS.
There are also some things in z/OS that are not in z/VSE, but the last
z/VSE to z/OS conversion I did, the client programmers hated the
'limitations' they found in z/OS and had to go do a lot of program
changes due to these limits.
Later, when I have time, I will list some of those things.
Please, do. It will be interesting.
Personally I don't know VSE, but heard about very few VSE advantages.
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-10 14:26:16 UTC
Permalink
Raw Message
[Default] On 10 Jul 2018 06:16:08 -0700, in bit.listserv.ibm-main
Post by Tony Thigpen
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.
z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there are many things in z/VSE that I miss in z/OS. There
are also some things in z/OS that are not in z/VSE, but the last z/VSE
to z/OS conversion I did, the client programmers hated the 'limitations'
they found in z/OS and had to go do a lot of program changes due to
these limits.
Later, when I have time, I will list some of those things.
Thes could and should lead to some RFEs being submitted.

Clark Morris
Post by Tony Thigpen
Tony Thigpen
Post by ITschak Mugzach
... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).
ITschak
Post by Dana Mitchell
My memories of VSE JCL are dated, and quite possbily incorrect with
current VSE, but I recall that I felt it was more complicated that MVS
jcl. It had more types of statements (although fewer parms per type),
JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To
describe a disk file, potentially required at least 3 statements, ASSIGN,
DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline
files were not interchangeable as far as programs were concerned.
An interesting 'feature' was that syntax checking was done at execution
time, so when a JCL error was encountered, a console message was issued
that required a reply, allowing you to retype the errant statement. So in
the days of real card readers, if you needed to make a quick one time
change to a job, you could just flip the card around backwards, causing
'Invalid Statement' console message prompt, allowing you to type in the
statement you really wanted.
Dana
How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL
probably are
irrelevant.
Clark Morris
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-10 15:19:04 UTC
Permalink
Raw Message
It wouldn't help; lots of people don't know what they platform that they are running on can do, much less other platforms. If I had $1 for every time somebody told me that, e.g., ISPF, couldn't do that I'd been doing for decades ...


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tony Thigpen <***@VSE2PDF.COM>
Sent: Tuesday, July 10, 2018 9:15 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement

I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer. DOS came out before what ever MVS was called back then.

z/VSE has a lot of things in the JCL that z/OS has no equal to. I work
both areas and there are many things in z/VSE that I miss in z/OS. There
are also some things in z/OS that are not in z/VSE, but the last z/VSE
to z/OS conversion I did, the client programmers hated the 'limitations'
they found in z/OS and had to go do a lot of program changes due to
these limits.

Later, when I have time, I will list some of those things.

Tony Thigpen
Post by ITschak Mugzach
... And I may add that if VSE JCL was so good, it wouldn't have so many
private extensions (and I've seem some of them).
ITschak
Post by Dana Mitchell
My memories of VSE JCL are dated, and quite possbily incorrect with
current VSE, but I recall that I felt it was more complicated that MVS
jcl. It had more types of statements (although fewer parms per type),
JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To
describe a disk file, potentially required at least 3 statements, ASSIGN,
DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline
files were not interchangeable as far as programs were concerned.
An interesting 'feature' was that syntax checking was done at execution
time, so when a JCL error was encountered, a console message was issued
that required a reply, allowing you to retype the errant statement. So in
the days of real card readers, if you needed to make a quick one time
change to a job, you could just flip the card around backwards, causing
'Invalid Statement' console message prompt, allowing you to type in the
statement you really wanted.
Dana
How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL
probably are
irrelevant.
Clark Morris
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2018-07-10 15:28:25 UTC
Permalink
Raw Message
Post by Seymour J Metz
It wouldn't help; lots of people don't know what they platform that they
are running on can do, much less other platforms. If I had $1 for every
time somebody told me that, e.g., ISPF, couldn't do that I'd been doing for
decades ...
​Yeah, it applies to live in general. I'm having a discussion on another,
gaming, forum where one person insists that I simply can't be doing what I
have been for about a month. Because I'm using a tool which "can't do
that".​
Post by Seymour J Metz
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
--
There is no such thing as the Cloud. It is just somebody else’s computer.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-10 18:23:45 UTC
Permalink
Raw Message
I have a few minutes, so I thought I would make some more comments.

1) z/OS JCL statements are much more complex than z/VSE because they
have a lot more 'options'. But, to be honest, most programmers just use
a small sub-set of what they could use.

Take a simple "I want to use a VSAM file". Here is what is normally used:
z/OS:
//POLYUPD DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR
z/VSE:
// DLBL TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC

There are two major differences here:

z/OS (mostly) requires a DISP=. VSE (mostly) does not. VSE determines
the correct setting at open time.

z/VSE (mostly) requires a CAT=. z/OS uses ICF catalogs and can figure it
out by itself. This can be good or it can be bad. In z/VSE, almost every
shop will have files with the same name located in different catalogs.
This goes back to testing. With z/VSE, each partition (equal to a z/OS
'initiator') can be set the same catalog name so that it points to a
different physical catalog.

I can see some of you thinking: "That would make security impossible."
No, it does not. z/VSE manages security based on not just file name, but
catalog name.

Personally, I think the advantage is to z/VSE when using VSAM files. Of
course, those of you that have never had the chance to test using
different catalogs may understand it's advantage.

(Both z/OS and z/VSE can specify buffer space, which is about the only
other option used on VSAM files, so that item is a wash.)


Next up will be non-VSAM files.

Tony Thigpen

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Dana Mitchell
2018-07-10 15:22:44 UTC
Permalink
Raw Message
Like I said, I was using cards when I last worked on VSE, so it's been a little while... ;)
I'll be curious to hear whats changed too

Dana
Post by Tony Thigpen
I wish those of you not current on VSE would remember that we have had
just as many years to change things as z/OS has. Oh, wait, we have
longer.
Later, when I have time, I will list some of those things.
Tony Thigpen
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-07-10 15:58:17 UTC
Permalink
Raw Message
Post by Clark Morris
How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS
JCL compare with VSE JCL? My memories of DOS360 JCL probably are
irrelevant.
I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine
that included essentially the entire Master Control Program (MCP) that ran on
the bigger machines.

I remember that Work Flow Language was considerably more powerful than JCL,
but I don't remember any specifics. I had been working with JCL for a few years
at the time. I have a vague recollection that there were a few things that you
couldn't do in WFL that you could do in JCL.

I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't
find one, but I did find a 6700/7700 System Software Handbook that has a
section on WFL.
http://bitsavers.trailing-edge.com/pdf/burroughs/B6500_6700/5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf

I also found a Unisys Work Flow Language Manual at
https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86001047-516

The 1700 was a very odd machine that allowed for bit-addressable memory.
While the physical memory was organized as 8-bit bytes, the higher level
languages all had their own "interpreter", each of which allowed for allocation
of storage on any bit boundary and with arbitrary bit length.

The interpreters were the microcode to support a given language. There
was one for Cobol, another for Fortran, and yet another for SDL. I
understood SDL to be a subset of Algol, and it was the language that
was used to write the MCP. Each interpreter was optimized for the
language that it was designed for.

Compiled instructions were of variable size, depending on the
requirements of the program. A program that referenced few data items
would need fewer bits in the instruction to reference those data items
than one that referenced many data items.

Pages were similarly variable in size, depending upon the requirements
of the program that was running.

Storage could be allocated in arbitrary increments. I did some
experimentation and IIRC, I found that I could do the equivalent of a
GETMAIN for 1 bit and it would be honored. Regardless of the size, a
48-bit header would be defined to describe it.

If you want a peek into this rather odd system, here is a link the the
1700 System Reference manual:
http://bitsavers.trailing-edge.com/pdf/burroughs/B1700/1057155_B1700SysRefMan11-73.pdf

And for a peek into the Master Control Program, the MCP reference
manual can be found at:
http://bitsavers.trailing-edge.com/pdf/burroughs/B1700/1088010B_1700MCPRefManAug75.pdf

Perhaps another time I will tell the tale of what we bought the
computer for and what happened with it.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-10 17:37:45 UTC
Permalink
Raw Message
It's not at all unusual that when you have experience with multiple systems, you find features on each that you wish you had on the others, e.g., in TSO I miss XEDIT.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tom Marchant <0000000a2a8c2020-dmarc-***@listserv.ua.edu>
Sent: Tuesday, July 10, 2018 11:58 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
Post by Clark Morris
How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and
successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS
JCL compare with VSE JCL? My memories of DOS360 JCL probably are
irrelevant.
I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine
that included essentially the entire Master Control Program (MCP) that ran on
the bigger machines.

I remember that Work Flow Language was considerably more powerful than JCL,
but I don't remember any specifics. I had been working with JCL for a few years
at the time. I have a vague recollection that there were a few things that you
couldn't do in WFL that you could do in JCL.

I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't
find one, but I did find a 6700/7700 System Software Handbook that has a
section on WFL.
http://secure-web.cisco.com/1oaw3qgL4gjrPhX7F7mKUCWRYzVJCVNgBwvF4n69Tyh4AiTXZYpvdbYElQO_gQk39Aw8SKZL9EXHZxQC8j-HRQRZzE7dlu451IHUVHWRfCJtQ00yp5sP3tstyn70_nPF6jmBoZUYcr-9WsLkk3GQgxMPY6nEZ7ACnOrZvpA34fbcaetW1zYw5Vt6gheD3oNbMwgEhltw22YM32Lj5CJDN_QDcjNYf8R6VKTHVEi5KYN0IHZMPYXf6d4KjudGDEMh2PmecWl8oZZr2bOSkFLbzq-GZtvS0xmWFuKj3bPJz4GYa7E01_eypOi0haPjAeqCj29TtqDZUdB1Ll2lGlmMF1EAxNzR77A5iQsuvJgokfUnhlv2QGGJzURH-6JVXxr0GsisYrwaY1Mtu_nfA3YVqTsoVIEPHGfxK_tVzH728vEZ9fEh1KT3yQd3Qlw5rymmn/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB6500_6700%2F5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf

I also found a Unisys Work Flow Language Manual at
https://secure-web.cisco.com/1kA_uHiE-G1A7sGXBC5HoPSMp5fW4vfvjFj5j9xycmrZNaam7iTrPXi7J99dfmimzEXSQCvlEIWLVYTmqWIi_ppQXx7EhcWis6req-sTPOZAtLv0v9Qab-cy0PPqtJh0w9WRFiLO0GI-HF9EeHHQY9Hs7Z8wJEhMidWMTfzD-ZjsEhgtvoWzsw6cuX_vykPZkrmb50ARjm-rUHSkpvXaO4ApAY8TlxyULBeNyd08Y93MMaAQmgInbaZZOrQO1V8Vauv4GVEj7FXBJktaBNDTPmQGKUqpiO7HrDzWMNzq30bqN4qf9bxz31b0FwUGcS-lX8Cz-q2tI3WODN3fH66YKPlgTQhaGIh2YS_4lLn_4DoGWpvvT2FdziNB9hASYBgAUHKxC0B8Gq2X3fkJ4LshGOKnFi07gS6IkA53XatQ5fEfg0YfePYAasZr35Bt2-9xP/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516

The 1700 was a very odd machine that allowed for bit-addressable memory.
While the physical memory was organized as 8-bit bytes, the higher level
languages all had their own "interpreter", each of which allowed for allocation
of storage on any bit boundary and with arbitrary bit length.

The interpreters were the microcode to support a given language. There
was one for Cobol, another for Fortran, and yet another for SDL. I
understood SDL to be a subset of Algol, and it was the language that
was used to write the MCP. Each interpreter was optimized for the
language that it was designed for.

Compiled instructions were of variable size, depending on the
requirements of the program. A program that referenced few data items
would need fewer bits in the instruction to reference those data items
than one that referenced many data items.

Pages were similarly variable in size, depending upon the requirements
of the program that was running.

Storage could be allocated in arbitrary increments. I did some
experimentation and IIRC, I found that I could do the equivalent of a
GETMAIN for 1 bit and it would be honored. Regardless of the size, a
48-bit header would be defined to describe it.

If you want a peek into this rather odd system, here is a link the the
1700 System Reference manual:
http://secure-web.cisco.com/1xDyW-vu-Dv_UI3m_YIQJyBu0rsCua4aPfkBHXhbwiEqORd0isbbjz6sSCQsVdHhy_byXdI4rVT8eMQuKWC6zUOyHFiBPgHbCaQV5cQaK1tUKYmbZGgUyC8iU0GJoabzUWpkjekGi_d2JeUMTeo5fKuAkD53eedbqjwOO0pptPzMhdOvO8PDyx9Lz3_rZcj_3K_nRedOxCGJIvvwDUJdwCuEgjFmJsM5TzBtdn-JUuqb2B8eGNqk5Jgn6AP8Vm5fBF-OAl1MVcSK-hD-Qb4pC8yCfWdUP1O063v3jnD1m_REvVUpw8XIoQdiZh5G0lqSbrv4QhaHN2FIS6BQ7tYiwFnzXPHJNHhsdA9xszkPt-qGD6qkgmFH5SZsBunPt153KglTNxPkHplpcUn0SDnEmo4DZQSeSKMP6djqSmI_Wbj9XjiuV8dFvpmJak0ssj7Zo/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB1700%2F1057155_B1700SysRefMan11-73.pdf

And for a peek into the Master Control Program, the MCP reference
manual can be found at:
http://secure-web.cisco.com/1jgVvG2NXgtINUsPr--k-6ww_14W_1jm3G55RaQ9Ym4kvSHcWPejWSY2br-fpJb4mQwvkZDxl_Q8PLjg7zyfYtWLxa8gm8tYWdsb45rwa8Vf8mc4-NnaJ9uYttZG7ML94p0sNwO7VKuu1ZsJ5vTk4xwiSVqB2wgfB-Xh9xBbY7D4ZbpM4xDSrrEF_biKEari9J3lsO6xxNjAKmOfuMJO1kDxVgqlIlpXZVlm2GJSgNoZrLMwGst3L6h3JUfzsjL41GDP_TdjzjUcXqmOaw3s2iTEcDu9beNSqD6mGWNdZKOZdnCAEr3v7q8P0JOpOR9Ox0A6jCy5UKkhyNyj7gbqOgqjquLr0xfLRBRH73K_CG5myzZQHLqjcvrIyIcwed9rXdpnJcrfbgOQNkHMwkOpB4aPmw03AiMcTDsWyXTHHyiJ81KNIZpfcFRlIFaNp0iiy/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB1700%2F1088010B_1700MCPRefManAug75.pdf

Perhaps another time I will tell the tale of what we bought the
computer for and what happened with it.

--
Tom Marchant

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-07-10 16:06:51 UTC
Permalink
Raw Message
Post by John McKown
I'm having a discussion on another,
gaming, forum where one person insists that I simply can't be doing what I
have been for about a month. Because I'm using a tool which "can't do
that".​
When my daughter was in high school she wrote a version of Space Invaders
for the TI-84 graphing calculator. She learned a lot about optimizing code for
performance with that project.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-10 18:48:20 UTC
Permalink
Raw Message
Post by Tony Thigpen
//POLYUPD DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR
// DLBL TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC
z/OS (mostly) requires a DISP=. VSE (mostly) does not. VSE determines
the correct setting at open time.
How can it infer the difference between KEEP and DELETE? (Or is that
the "mostly" part?)

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Wayne Bickerdike
2018-07-10 19:52:14 UTC
Permalink
Raw Message
*How can it infer the difference between KEEP and DELETE? (Or is thatthe
"mostly" part?)-- gil*


*On Wed, Jul 11, 2018 at 4:48 AM, Paul Gilmartin
*On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote: > >Take a simple
//POLYUPD DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR >z/VSE: >// DLBL
TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC > >z/OS (mostly) requires a
DISP=. VSE (mostly) does not. VSE determines >the correct setting at open
time. > How can it infer the difference between KEEP and DELETE? (Or is
that the "mostly" part?) -- gil *
* ----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
INFO IBM-MAIN *
How does z/OS have a JCL DELETE option for a VSAM file? As far as I know,a
VSAM file has to be explicitly DELETE/DEFINED using IDCAMS.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Farley, Peter x23353
2018-07-10 20:05:21 UTC
Permalink
Raw Message
z/OS DISP=(OLD,DELETE) works without any problem to delete a VSAM cluster that you own. I use that JCL all the time to delete test VSAM files.

Creating a VSAM cluster may often require IDCAMS DEFINE, but the JCL LIKE parameter is your friend if for instance you are making a copy of a production file for a unit test run. Just use the UNIT and SPACE parameters to allocate space and all else will be copied from the LIKE cluster.

Now if any of the LIKE cluster parameters are incompatible with your immediate need (REUSE vs NOREUSE perhaps, or LOG parameters for RLS) then you do need DEFINE, but the JCL DELETE works without an issue that I am aware of.

Peter

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Wayne Bickerdike
Sent: Tuesday, July 10, 2018 3:52 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files

*How can it infer the difference between KEEP and DELETE? (Or is thatthe
"mostly" part?)-- gil*


*On Wed, Jul 11, 2018 at 4:48 AM, Paul Gilmartin
*On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote: > >Take a simple
//POLYUPD DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR >z/VSE: >// DLBL
TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC > >z/OS (mostly) requires a
DISP=. VSE (mostly) does not. VSE determines >the correct setting at open
time. > How can it infer the difference between KEEP and DELETE? (Or is
that the "mostly" part?) -- gil *
How does z/OS have a JCL DELETE option for a VSAM file? As far as I know,a
VSAM file has to be explicitly DELETE/DEFINED using IDCAMS.
--


This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-10 22:05:52 UTC
Permalink
Raw Message
On z/VSE, there is not a LIKE option in the DLBL card. We must use
IDCAMS DEFINE with MODEL(other file name) to get the same results as LIKE.

Tony Thigpen
Post by Farley, Peter x23353
Creating a VSAM cluster may often require IDCAMS DEFINE, but the JCL LIKE parameter is your friend if for instance you are making a copy of a production file for a unit test run. Just use the UNIT and SPACE parameters to allocate space and all else will be copied from the LIKE cluster.
Now if any of the LIKE cluster parameters are incompatible with your immediate need (REUSE vs NOREUSE perhaps, or LOG parameters for RLS) then you do need DEFINE, but the JCL DELETE works without an issue that I am aware of.
Peter
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2018-07-11 14:34:14 UTC
Permalink
Raw Message
Post by Farley, Peter x23353
z/OS DISP=(OLD,DELETE) works without any problem to delete a VSAM cluster that you own. I use that JCL all the time to delete test VSAM files.
Creating a VSAM cluster may often require IDCAMS DEFINE, but the JCL LIKE parameter is your friend if for instance you are making a copy of a production file for a unit test run. Just use the UNIT and SPACE parameters to allocate space and all else will be copied from the LIKE cluster.
UNIT? That old JCL keyword commonly used in the dark ages before SMS?
;-)
Post by Farley, Peter x23353
Now if any of the LIKE cluster parameters are incompatible with your immediate need (REUSE vs NOREUSE perhaps, or LOG parameters for RLS) then you do need DEFINE, but the JCL DELETE works without an issue that I am aware of.
Sometimes DATACLAS=dataclass can help. So, you can use
LIKE=ORIGINAL.CLUSTER,DATACLAS=NOREUSE,SPACE=(CYL,(10,10))
--
Radoslaw Skorupka
Lodz, Poland




======================================================================


--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.

This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: ***@mBank.plSąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Clifford
2018-07-10 20:16:13 UTC
Permalink
Raw Message
Z/os VSAM is always accessed as DISP=SHR.
Post by Wayne Bickerdike
*How can it infer the difference between KEEP and DELETE? (Or is thatthe
"mostly" part?)-- gil*
*On Wed, Jul 11, 2018 at 4:48 AM, Paul Gilmartin
*On Tue, 10 Jul 2018 14:23:34 -0400, Tony Thigpen wrote: > >Take a simple
//POLYUPD DD DSN=PROD.HKY.VSAM.HPP002P.F03,DISP=SHR >z/VSE: >// DLBL
TEITEST,'TEI.TEST.VSAM',,VSAM,CAT=VSESPUC > >z/OS (mostly) requires a
DISP=. VSE (mostly) does not. VSE determines >the correct setting at open
time. > How can it infer the difference between KEEP and DELETE? (Or is
that the "mostly" part?) -- gil *
* ----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email
INFO IBM-MAIN *
How does z/OS have a JCL DELETE option for a VSAM file? As far as I know,a
VSAM file has to be explicitly DELETE/DEFINED using IDCAMS.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-10 21:43:29 UTC
Permalink
Raw Message
Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them
they did not have to do it.)

Tony Thigpen
Post by John Clifford
Z/os VSAM is always accessed as DISP=SHR.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2018-07-10 21:49:59 UTC
Permalink
Raw Message
If DISP=SHR (that is if not DISP is provided), then the JCL Default of (NEW,PASS) would happen and the job would fail
Post by Charles Mills
-----Original Message-----
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 2:43 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them they
did not have to do it.)
Tony Thigpen
Post by John Clifford
Z/os VSAM is always accessed as DISP=SHR.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-10 22:08:00 UTC
Permalink
Raw Message
So, DISP=SHR is not the default, as I thought was implied by John's
statement that "Z/os VSAM is always accessed as DISP=SHR."

Tony Thigpen
Post by Gibney, Dave
If DISP=SHR (that is if not DISP is provided), then the JCL Default of (NEW,PASS) would happen and the job would fail
Post by Charles Mills
-----Original Message-----
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 2:43 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them they
did not have to do it.)
Tony Thigpen
Post by John Clifford
Z/os VSAM is always accessed as DISP=SHR.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2018-07-10 22:23:43 UTC
Permalink
Raw Message
Actually, I think that inside VSAM, what is specified via SHAREOPTIONS would override any JCL. But, you need to get past the JCL during allocation before VSAM can take over.
Post by Charles Mills
-----Original Message-----
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 3:08 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
So, DISP=SHR is not the default, as I thought was implied by John's statement
that "Z/os VSAM is always accessed as DISP=SHR."
Tony Thigpen
Post by Gibney, Dave
If DISP=SHR (that is if not DISP is provided), then the JCL Default of
(NEW,PASS) would happen and the job would fail
Post by Charles Mills
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 2:43 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told
them they did not have to do it.)
Tony Thigpen
Post by John Clifford
Z/os VSAM is always accessed as DISP=SHR.
---------------------------------------------------------------------
- For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John Clifford
2018-07-10 22:33:56 UTC
Permalink
Raw Message
it is not the default but is the only correct way to access a vsam file.
disp=shr,dsn=xxxx.vsam (possible bufno,bufni,...etc)

Never disp=new or delete. Disp=old can be used if you need to make sure
you are the only one accessing the file but if it is open in CICS it will
hang.
Post by Tony Thigpen
So, DISP=SHR is not the default, as I thought was implied by John's
statement that "Z/os VSAM is always accessed as DISP=SHR."
Tony Thigpen
Post by Gibney, Dave
If DISP=SHR (that is if not DISP is provided), then the JCL Default of
(NEW,PASS) would happen and the job would fail
-----Original Message-----
Post by Charles Mills
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 2:43 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them they
did not have to do it.)
Tony Thigpen
Post by John Clifford
Z/os VSAM is always accessed as DISP=SHR.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-11 01:05:23 UTC
Permalink
Raw Message
[Default] On 10 Jul 2018 15:08:00 -0700, in bit.listserv.ibm-main
Post by Tony Thigpen
So, DISP=SHR is not the default, as I thought was implied by John's
statement that "Z/os VSAM is always accessed as DISP=SHR."
Not only that but I have accessed VSAM DISP=OLD when I wanted
exclusive access. Normallypeople let the share options rule.

Clark Morris
Post by Tony Thigpen
Tony Thigpen
Post by Gibney, Dave
If DISP=SHR (that is if not DISP is provided), then the JCL Default of (NEW,PASS) would happen and the job would fail
Post by Charles Mills
-----Original Message-----
On Behalf Of Tony Thigpen
Sent: Tuesday, July 10, 2018 2:43 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
Then, why does every VSAM DD for every z/OS site I have worked with,
always include DISP=SHR?
(I guess, because it's a habit from non-VSAM files and nobody told them they
did not have to do it.)
Tony Thigpen
Post by John Clifford
Z/os VSAM is always accessed as DISP=SHR.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2018-07-11 13:36:47 UTC
Permalink
Raw Message
DISP=NEW or OLD is perfectly valid for VSAM and PDSEs. PDSEs presumably
use some kind of hidden paging interface like LINEAR and ZFS do, but are
not VSAM.

sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Thigpen
2018-07-10 22:01:31 UTC
Permalink
Raw Message
For normal z/VSE VSAM:
1) you can use DISP=NEW, which resets the High RBA at open if the file
is defined with REUSE.
2) you can use DISP=DELETE, which resets the High RBA at close if the
file is defined as REUSE. (note: Space is not released.)
3) with very limited exceptions, you always use IDCAMS to define or
delete the VSAM file.
4) the default is DISP=(OLD,KEEP,KEEP) is the default.

The limited exception mentioned is when using "VSAM managed SAM files".
You don't have these on z/OS. (AFAIK) I will discuss them after I
discuss regular non-VSAM files.

So, for most situations, DISP= is not specified on the z/VSE DLBL card.

Tony Thigpen
Post by Wayne Bickerdike
*How can it infer the difference between KEEP and DELETE? (Or is thatthe
"mostly" part?)-- gil*
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-10 22:07:16 UTC
Permalink
Raw Message
Post by Gibney, Dave
If DISP=SHR (that is if not DISP is provided), then the JCL Default of (NEW,PASS) would happen and the job would fail
From the JCL Ref.
Defaults
v If you omit the status subparameter, the default is NEW.
v If you omit the normal termination disposition subparameter, the default is
DELETE for a NEW data set or KEEP for an existing data set.

Hmmm. Does this mean that fmr status MOD the data set will be deleted if allocation
created it but kept if it existed beforehand?

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Gibney, Dave
2018-07-10 22:21:46 UTC
Permalink
Raw Message
My memory was wrong on normal termination. I rarely use DISP defaults. I would expect you are correct for the MOD instance
Post by Charles Mills
-----Original Message-----
On Behalf Of Paul Gilmartin
Sent: Tuesday, July 10, 2018 3:07 PM
Subject: Re: z/OS JCl vs. VSE JCL: VSAM files
Post by Gibney, Dave
If DISP=SHR (that is if not DISP is provided), then the JCL Default of
(NEW,PASS) would happen and the job would fail
From the JCL Ref.
Defaults
v If you omit the status subparameter, the default is NEW.
v If you omit the normal termination disposition subparameter, the default is
DELETE for a NEW data set or KEEP for an existing data set.
Hmmm. Does this mean that fmr status MOD the data set will be deleted if
allocation created it but kept if it existed beforehand?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
w***@gmail.com
2018-07-11 08:32:35 UTC
Permalink
Raw Message
@Clem Clarke, I assume that there must more to a JOL 'job' than what you show.
'Exec Validate' and 'Exec Update' looks like procedure calls, so the procedures must be defined too. At the very least the relationship between libref and datasetname must be defined somwehere, as must the specifications for new datasets.

Willy
Loading...