Re: REXX as JCL replacement
Ah, OK. We didn't have a tape/disk manager.
From: IBM Mainframe Discussion List on behalf of
Tony Thigpen
Sent: Thursday, July 12, 2018 8:10 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
All the main disk and tape managers have GDGs.
Tony Thigpen
Frank Swarbrick wrote on 07/12/2018 06:06 PM:
> Since when does z/VSE have GDGs??
>
> From: IBM Mainframe Discussion List on behalf of
> Tony Thigpen
> Sent: Wednesday, July 11, 2018 1:35 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: REXX as JCL replacement
>
> Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
> created in a step, it becomes the current GDG for all following steps.
> So, following steps don't need to reference +1, then require a change
> during a restart.
>
> It part of the difference that z/OS reads the whole job in then
> allocates everything where as z/VSE only reads the following JCL after
> the previous step has completed.
>
> Tony Thigpen
>
> John McKown wrote on 07/11/2018 01:30 PM:
>> On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
>> wrote:
>>
>> I, like many here, am old enough to remember how much of a PITA
>> it was to restart a job when a step failed for some reason. Mainly deleting
>> datasets, but also changing GDG relative generation numbers if the restart
>> is after the step which created the new GDG which is used in subsequent
>> steps. {shudder}
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [SPAM] Re: REXX as JCL replacement - Performance
JCL can submit further jobs to the internal reader to get around the 255 steps limit. Loops can be implemented in JCL by submitting a job that then resubmits itself n times, based on a counter passed in a dataset (and decremented at each resubmission) and on a same LPAR. A jobstep that creates a new GDG entry would create it as *.GDG(+1) and all subsequent steps would then refer to it as *.GDG(0) - hence there would be no problem with restarting a same job from a subsequent step onwards. A job's Boolean logic processing can be implemented through COND= testing alone, using IEFBR14 'dummy' steps. The only useful purpose REXX could serve would be to submit one or more jobs *as JCL* to the internal reader, but in a same way that CONTROL-M already does. REXX could not replace JCL: it would be unmaintainable. Chris Poncelet On 14/07/2018 00:46, Robert Prins wrote: > On 2018-07-13 01:29, CM Poncelet wrote: >> What 'problem' with JCL is fixed by replacing it with REXX? > > REXX doesn't have a limit of 255 steps in a job, and that limit may be > reached when doing regression tests. It also allows loops. Example I > have is too long to post here (probably). > > Robert -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
[SPAM] Re: REXX as JCL replacement - Performance
On 2018-07-13 01:29, CM Poncelet wrote: What 'problem' with JCL is fixed by replacing it with REXX? REXX doesn't have a limit of 255 steps in a job, and that limit may be reached when doing regression tests. It also allows loops. Example I have is too long to post here (probably). Robert -- Robert AH Prins robert.ah.prins(a)gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement - Performance
No sane person would seriously advocate the "demise" of JCL. All the slings & arrows it's suffered here lately are just the motivation for trying alternatives; or for some proposed enhancements. The continued existence and use of JCL (moot anyway) is no impediment to the alternatives. sas On 7/14/2018 9:47, Paul Gilmartin wrote: On Sat, 14 Jul 2018 09:30:37 +, Robert Prins wrote: On 2018-07-13 01:29, CM Poncelet wrote: What 'problem' with JCL is fixed by replacing it with REXX? REXX doesn't have a limit of 255 steps in a job, and that limit may be reached when doing regression tests. It also allows loops. Example I have is too long to post here (probably). Rexx is available. If Rexx meets your needs, then simply use Rexx. But why clamor, apparently for the demise of JCL? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement - Performance
On Sat, 14 Jul 2018 09:30:37 +, Robert Prins wrote: >On 2018-07-13 01:29, CM Poncelet wrote: > > What 'problem' with JCL is fixed by replacing it with REXX? > >REXX doesn't have a limit of 255 steps in a job, and that limit may be reached >when doing regression tests. It also allows loops. Example I have is too long >to >post here (probably). > Rexx is available. If Rexx meets your needs, then simply use Rexx. But why clamor, apparently for the demise of JCL? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement - Performance
On 2018-07-13 01:29, CM Poncelet wrote: > What 'problem' with JCL is fixed by replacing it with REXX? REXX doesn't have a limit of 255 steps in a job, and that limit may be reached when doing regression tests. It also allows loops. Example I have is too long to post here (probably). Robert -- Robert AH Prins robert.ah.prins(a)gmail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
I was not involved, but I will reach out to the ones that were.
Tony Thigpen
Clem Clarke wrote on 07/13/2018 05:07 AM:
Perhaps Tony you could say why Jol was rejected?
Thanks,
Clem
Tony Thigpen wrote:
Using pipelines could require a lot of programming changes.
Historically, programs tend to be designed to process batches, not
records.
Most shops will not have the bodies to do the changes needed.
I like the idea of REXX as a JCL replacement. It can provide a lot
better logic. I don't know that it will make many inroads due to lack
of man-power, but it can be a method to the future.
One of our staff looked seriously at JOL and rejected it.
Tony Thigpen
Hobart Spitz wrote on 07/11/2018 08:37 AM:
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.
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford
wrote:
On 11/07/2018 7:19 AM, Clem Clarke wrote:
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
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Perhaps Tony you could say why Jol was rejected?
Thanks,
Clem
Tony Thigpen wrote:
Using pipelines could require a lot of programming changes.
Historically, programs tend to be designed to process batches, not
records.
Most shops will not have the bodies to do the changes needed.
I like the idea of REXX as a JCL replacement. It can provide a lot
better logic. I don't know that it will make many inroads due to lack
of man-power, but it can be a method to the future.
One of our staff looked seriously at JOL and rejected it.
Tony Thigpen
Hobart Spitz wrote on 07/11/2018 08:37 AM:
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.
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford
wrote:
On 11/07/2018 7:19 AM, Clem Clarke wrote:
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
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Oh! Didn't know that. I moved to the East Coast of Australia, and lost contact... David Crayford wrote: On 11/07/2018 7:19 AM, Clem Clarke wrote: 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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Tony Thigpen - very observant. Yes, there is an optional back-end database for Data Set Information. This was originally added to Jol so that the people in the department looking after the Data Sets on the machine could be separate from the people writing the code to actually execute the programs. Then in order to make Jol more useful (and a universal command language) the data set and program information such as the DDnames, and whether they read or write (ie create) files was hidden. The intention with Jol was always to be a Universal Command Language - and hence commands and so on have always been built in an English like manner, with compatibility always in mind. You can see the list of commands on this page. Press on the: 'Detailed descriptions of Jol Instructions' on this page: http://start.oscar-jol.com/documentation/technical-how-to-use Also, you can see the general format of a Jol program by following the 'Jol Reference Guide' link. -- Originally, people use Jol instructions to declare programs and data sets and used the Run instruction which tied the declares together to create the JCL to execute the program. Here is a simple example of the "low" level Jol. Job1: Job 10,5 mins acct dept01 250M; Dcl Output DS temporary.file vb 200, 6144 unit sysda vol vol01; Dcl Input DS Sys1.maclib(call); Dcl Printer Print; Dcl Iebgener Program sysut1 reads input sysut2 writes output sysin reads 'dummy' sysprint writes Printer; Run Iebgener; -- The above can be simplified to: Dcl Output DS temporary.file vb 200, 6144 unit sysda vol vol01; Dcl Input DS Sys1.maclib(call); Copy Input to Output; --- Or further Copy 'sys1.maclib(call)' to temporary.file; Tony Thigpen wrote: 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 Clem Clarke wrote on 07/10/2018 08:33 PM: 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'; -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
All the main disk and tape managers have GDGs.
Tony Thigpen
Frank Swarbrick wrote on 07/12/2018 06:06 PM:
Since when does z/VSE have GDGs??
From: IBM Mainframe Discussion List on behalf of Tony
Thigpen
Sent: Wednesday, July 11, 2018 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
created in a step, it becomes the current GDG for all following steps.
So, following steps don't need to reference +1, then require a change
during a restart.
It part of the difference that z/OS reads the whole job in then
allocates everything where as z/VSE only reads the following JCL after
the previous step has completed.
Tony Thigpen
John McKown wrote on 07/11/2018 01:30 PM:
On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
wrote:
I, like many here, am old enough to remember how much of a PITA
it was to restart a job when a step failed for some reason. Mainly deleting
datasets, but also changing GDG relative generation numbers if the restart
is after the step which created the new GDG which is used in subsequent
steps. {shudder}
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement - Performance
Yes, runnning in programs batch is always more efficient than in TSO - just as invoking assembler programs from REXX is more efficient than invoking REXX from assembler (via "ISPLINK" is it?) If JCL is 'strange', consider then native SMP/E. I never had a problem with JCL or with native SMP/E (and I ignored all IBM's attempts at enforcing SMP/E dialogs in the late 80s and 'custompak' etc. in the late 90s.) What 'problem' with JCL is fixed by replacing it with REXX? Chris Poncelet CEng MBCS CITP (retired sysprog consultant) On 12/07/2018 17:38, Nightwatch RenBand wrote: > My information may be out of date... but as I remember someone, possibly > Barry Merrill, did the research and found that running a program under TSO > cost about three times what it cost in batch. And REXX's are usually run > in a TSO environment, even when run as TSO-Batch. > Has this changed? > Perhaps my assumptions about TSO-batch are inaccurate. > But if correct, that pretty much answers why REXX is not a good replacement > for JCL. Yes, JCL is strange and takes some getting used to, but no more > so than English for Chinese speakers, or visa versa. And giving JCL its > due, the overhead it uses is minimal. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > . > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Since when does z/VSE have GDGs??
From: IBM Mainframe Discussion List on behalf of
Tony Thigpen
Sent: Wednesday, July 11, 2018 1:35 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: REXX as JCL replacement
Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
created in a step, it becomes the current GDG for all following steps.
So, following steps don't need to reference +1, then require a change
during a restart.
It part of the difference that z/OS reads the whole job in then
allocates everything where as z/VSE only reads the following JCL after
the previous step has completed.
Tony Thigpen
John McKown wrote on 07/11/2018 01:30 PM:
> On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
> wrote:
>
> I, like many here, am old enough to remember how much of a PITA
> it was to restart a job when a step failed for some reason. Mainly deleting
> datasets, but also changing GDG relative generation numbers if the restart
> is after the step which created the new GDG which is used in subsequent
> steps. {shudder}
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
> REXXTRY is roughly to REXX what csh is to C.
?
csh does not read C statements and execute them; it's a scripting language.
REXXTRY is not a scripting language, although it is a great convenience for the
REXX programmer.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Hobart Spitz
Sent: Monday, July 9, 2018 3:20 PM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
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. If you don't have REXXTRY, you can find the source on the web. I
would recommend one of the IBM versions.
For example (untested):
1. *//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
2. *// JCLLIB ORDER=(MY.JCL.LIB) Optional*
3. *// EXEC TSO,CMD=REXXTRY*
4. *//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN
use.*
5. *Trace = "e" /* Unique to REXXTRY. Show error commands. You may
prefer "c". */*
6. *"profile"*
7. *call outtrap "Lines."*
8. *"st myjobname"*
9. *call outtrap "off"*
10. *parse var Lines.1 "(" JESNum ")" /* cutting some corners here in
interest of brevity */*
11. *"%myrexpgm"*
12. *OutDSN = "out.data(results)"*
13. *DSStat = sysdsn(OutDSN)*
14. *if DSStat == "OK" | DSStat == "MEMBER NOT FOUND" then **DSOptions =
"shr"*
15. *if DSStat == "DATASET NOT FOUND" then **DSOptions = "new
catalog cyl space(10 10) dsntype(library)"*
16. *if var("DSOptions") == "LIT" then do;** say time() Lines.1 OutDSN
"-" DSStat; **exit 20; **end*
17. *"alloc reuse dd(sysut2) dsn("OutDSN")" DSOptions*
18. *if RC <> 0 then exit RC*
19. *"alloc reuse dd(sysin) dummy"*
20. *"alloc reuse dd(sysut1) shr dsn('my.in.data')"*
21. *"call *(iebgener)" /* Trace = "e" reports failures; GENER stops if
SYSIN/SYSUT1 missing/invalid. */*
22. *"free dd(sysut2, sysin, sysut1)"*
23. *//*
Here we can use SHR with our output PDSE if it already exists.
You must put ALLOCs, TSO CALLs, FREEs, and any other commands with
parentheses or characters that REXX is sensitive to, in quotes or quotation
marks. Quotation marks ( " ) are prefered if you have fully qualified
dataset names with quotes. See line 20.
Lines 12 thru 18 could form the basis of a common, external routine, since
it may be needed often.
Personally, I think this approach is so much better that I might set
REXXTRY as the default &CMD value in the PROC. On the other hand, you
don't have multil-line commands, continuations, the ability to supply
internal routines or SIGNAL handlers, so at some point it becomes
preferable to make a long sequence of commands into a program of its own.
Maybe this is what a JCL replacement could look like. Add in some commands
for compatibility (e.g. JCL DD, JCL STEPEXEC, JCL SET, etc.), and things
look rosier and practical.
Caution: DD DDNAME=... and "alloc ddname(...)" are two completely
different animals.
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 9, 2018 at 12:56 PM, Steve Smith wrote:
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
> And IBM wisely originally implemented the POSIX shell, > only later caving to pressure from (t)csh partisans. IMHO it was shortsighted of IBM to only implement what they needed to get certification. The Eunix community had long since made certain optional facilities, e.g., csh, Perl, de facto standards for a usable *ix system. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, July 9, 2018 3:54 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Mon, 9 Jul 2018 15:20:07 -0400, Hobart Spitz wrote: >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. >For example (untested): > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
It's a piece of cake using REXX with ISPF Table Services. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Monday, July 9, 2018 8:56 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Mon, 9 Jul 2018 16:45:00 -0700, Charles Mills wrote: >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. On Mon, 9 Jul 2018 20:11:17 -0400, Steve Smith wrote: >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://secure-web.cisco.com/1Jgwmmw9bLf0xOyiZDG1PP1xIQg4CsupCNE-cVCbYmbzSZDMM3yKPaNSKAYszYfkF-qgdP7gUVy46NqcJZFPP9oJOOCIqLxwZPIUUb8mVrTavbnnx5w9VjO85EIlASos--nZ95hD6A6cjS7oDsmxSdAsBDIwTRHxNbEeXw2NDnhJyi6-39dzLNyj0D8ArB7L3EyFPi6M-jPPUFf2Wisd60J_-zaKOzpguch0JTIYpsQMPRh3rLe60Wmmvp9kyUTl98gNIlg-EpPg8IQ7r07hP_xhekRkemuENcHaHVrOtyawyPKCUHkfrha_uV6aKuxaxfKDVCLBdsb0u0Q7yRyXhcbGKoDjNTLx2Sumchu_BsNuQsVo8uqB21WybtdF8JIED6LV8-FkHwda8rVSbGglEKJ4POJQ00GLCDNxFmr5nZYftJsEmzC0ba42h7q4SqOua/https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSheepshead_%28game%29 ??? Calvinball? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Well, there's certainly some Algol 60 influence on the syntax, but it didn't have an Algol feel when I looked at it. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Farley, Peter x23353 Sent: Thursday, July 12, 2018 12:38 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement It was explained to me in my brief contact with the language back in the early 1970's that WFL was essentially a dialect of Algol 60 with no I/IO facilities. What it grew to become in later years I don't know. It would be interesting (if I had round tuits) to give the Unisys manual a thorough reading. Thanks for the link Tom. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, July 12, 2018 12:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement Thanks; looks like a primitive scripting language; I'd prefer Perl, REXX or even the shell that is not to be Bourne. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 11, 2018 5:30 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote: >Do you have a link to the WFL reference? I posted it yesterday. https://secure-web.cisco.com/1uGoP0952VN4w4AZzfClqI77QNAfSTIdStaktzZTvCZKZsViE894moWG8YNd7SSyXjllo3CNrc1b1wdzWmTwn8R56t07sLMF2ND3Aj2iRrzYNxbfyP9W94bD-1Ghdbac8Z0P7t6XNr7aXcq-Ig8TEzJHeQZ4d4LdElufEv186lfkNT4dRJ5ZmfNzrcViDnSnnseVEUJ6FTMtSxzTh6DpfshWT2rmRSHPL0Uy5fLkcc2mhLQBaQneKtV_aUsDi73YP7ppTdAyjDCzJCWVU3belLhCM_BFPkleSojvcPj0z7w9QunhTUNHARgTYtwhE1tU5Lwaq4cZKaRkvd5-rxc6Tf158IwX9OnCbx8X_rvCleepyYdx8fQKPcctnxhvIuyTJSf6-ewia9F8HdNBRZF9k0YjFdx09ODrCS7PagM0yOWCwtHh_dN5E2XZ3dejPeLFK/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516 -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
It was explained to me in my brief contact with the language back in the early 1970's that WFL was essentially a dialect of Algol 60 with no I/IO facilities. What it grew to become in later years I don't know. It would be interesting (if I had round tuits) to give the Unisys manual a thorough reading. Thanks for the link Tom. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, July 12, 2018 12:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement Thanks; looks like a primitive scripting language; I'd prefer Perl, REXX or even the shell that is not to be Bourne. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 11, 2018 5:30 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote: >Do you have a link to the WFL reference? I posted it yesterday. https://secure-web.cisco.com/1uGoP0952VN4w4AZzfClqI77QNAfSTIdStaktzZTvCZKZsViE894moWG8YNd7SSyXjllo3CNrc1b1wdzWmTwn8R56t07sLMF2ND3Aj2iRrzYNxbfyP9W94bD-1Ghdbac8Z0P7t6XNr7aXcq-Ig8TEzJHeQZ4d4LdElufEv186lfkNT4dRJ5ZmfNzrcViDnSnnseVEUJ6FTMtSxzTh6DpfshWT2rmRSHPL0Uy5fLkcc2mhLQBaQneKtV_aUsDi73YP7ppTdAyjDCzJCWVU3belLhCM_BFPkleSojvcPj0z7w9QunhTUNHARgTYtwhE1tU5Lwaq4cZKaRkvd5-rxc6Tf158IwX9OnCbx8X_rvCleepyYdx8fQKPcctnxhvIuyTJSf6-ewia9F8HdNBRZF9k0YjFdx09ODrCS7PagM0yOWCwtHh_dN5E2XZ3dejPeLFK/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516 -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Thanks; looks like a primitive scripting language; I'd prefer Perl, REXX or even the shell that is not to be Bourne. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 11, 2018 5:30 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote: >Do you have a link to the WFL reference? I posted it yesterday. https://secure-web.cisco.com/1uGoP0952VN4w4AZzfClqI77QNAfSTIdStaktzZTvCZKZsViE894moWG8YNd7SSyXjllo3CNrc1b1wdzWmTwn8R56t07sLMF2ND3Aj2iRrzYNxbfyP9W94bD-1Ghdbac8Z0P7t6XNr7aXcq-Ig8TEzJHeQZ4d4LdElufEv186lfkNT4dRJ5ZmfNzrcViDnSnnseVEUJ6FTMtSxzTh6DpfshWT2rmRSHPL0Uy5fLkcc2mhLQBaQneKtV_aUsDi73YP7ppTdAyjDCzJCWVU3belLhCM_BFPkleSojvcPj0z7w9QunhTUNHARgTYtwhE1tU5Lwaq4cZKaRkvd5-rxc6Tf158IwX9OnCbx8X_rvCleepyYdx8fQKPcctnxhvIuyTJSf6-ewia9F8HdNBRZF9k0YjFdx09ODrCS7PagM0yOWCwtHh_dN5E2XZ3dejPeLFK/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516 -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Why are positional problems an issue? They should be just as easy to parse as keyword parameters, although I probably wouldn't use REXX for the job. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Wednesday, July 11, 2018 4:45 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL has a name token format, almost nothing is positional. The aim was verifying security readiness of JCL, just like the JCL checkers but with security in mind. so migration is not a problem, but as others said, why migrate something that most time performs to something that sometimes performs? You miss an IF before the first exec? insert a dummy EXEC PGM-IEFBR14. Does nothing and allows the IF. ITschak On Wed, Jul 11, 2018 at 10:39 PM ITschak Mugzach wrote: > Yap. google "Work Flow Language (WFL) Programming Reference Manual pdf" to > get the PDF version. Just performing a pentest for a UNISYS client in > Europe and every-time i am surprised with the agility of it. > > ITschak > > On Wed, Jul 11, 2018 at 7:29 PM Seymour J Metz wrote: > >> Do you have a link to the WFL reference? >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List on behalf >> of ITschak Mugzach >> Sent: Wednesday, July 11, 2018 6:20 AM >> To: IBM-MAIN@listserv.ua.edu >> Subject: Re: REXX as JCL replacement >> >> Speaking of replacing JCL, how about unisys WFL? It's a programming >> language dedicated to job flows. BTW, I am happy with jcl... >> >> ITschak >> >> On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen wrote: >> >> > 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 >> > >> > Clem Clarke wrote on 07/10/2018 08:33 PM: >> > > 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=* >> > > //INTRANSDD 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) >> > > //SORTOUTDD 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=* >&g
Re: REXX as JCL replacement
On Wed, Jul 11, 2018, 14:01 Hobart Spitz wrote: > Sorry John. I know how businesses work. My comment was rude, sarcastic, > and uncalled for. I should not have sent it. > Cheerfully accepted. Compared to what a person said to me on a Per language "newbies" forum, your reply was, at most, chiding. > 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 Wed, Jul 11, 2018 at 2:48 PM, John McKown > > wrote: > > > On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz wrote: > > > > > John; So the production schedules set policy in your shop. Do they > pay > > > the bills too? > > > > > > > Well, they run the jobs which keep the company running which pays my > > salary. But if you want who, at least in the past, sets policy -- it was > > the end user departments. They demand, we supply. The most precious > > employees are the sales agents. No sales, no money. No money, no company. > > It runs down hill from there. I.e. the departments support the sales > force. > > We support the departments. So we are at the bottom of the support list. > > > > > -- > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On 7/11/2018 12:09 PM, Tom Marchant wrote: An example of an incremental improvement is IF/THEN/ELSE/ENDIF. I remember that - right about the time I finally understood how COND= worked. Of course I really didn't. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 11 Jul 2018 22:45:38 +0200, ITschak Mugzach wrote: >BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL >has a name token format, almost nothing is positional. > Parameters on JOB? Parameters on EXEC? Subparameters of DCB, LABEL, ...? (Well, you said "almost".) > ... You miss an IF before the first exec? insert a dummy EXEC >PGM-IEFBR14. Does nothing and allows the IF. > Why should such mickeymouse be necessary? Why shoudn't IF just behave intuitively, governing everything between THEN and ELSE/ENDIF? Why does it not issue at least warnings on use of unsupported/deprecated constructs? I consider this splendid evidence of "What's wrong with JCL?" And it's a new feature, hardly primeval. How did this ever pass design review? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 11 Jul 2018 17:29:28 +, Seymour J Metz wrote: >Do you have a link to the WFL reference? I posted it yesterday. https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86001047-516 -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
BTW, I wrote a rexx interpreter of JCL a year ago. ITs so easy because JCL has a name token format, almost nothing is positional. The aim was verifying security readiness of JCL, just like the JCL checkers but with security in mind. so migration is not a problem, but as others said, why migrate something that most time performs to something that sometimes performs? You miss an IF before the first exec? insert a dummy EXEC PGM-IEFBR14. Does nothing and allows the IF. ITschak On Wed, Jul 11, 2018 at 10:39 PM ITschak Mugzach wrote: > Yap. google "Work Flow Language (WFL) Programming Reference Manual pdf" to > get the PDF version. Just performing a pentest for a UNISYS client in > Europe and every-time i am surprised with the agility of it. > > ITschak > > On Wed, Jul 11, 2018 at 7:29 PM Seymour J Metz wrote: > >> Do you have a link to the WFL reference? >> >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Discussion List on behalf >> of ITschak Mugzach >> Sent: Wednesday, July 11, 2018 6:20 AM >> To: IBM-MAIN@listserv.ua.edu >> Subject: Re: REXX as JCL replacement >> >> Speaking of replacing JCL, how about unisys WFL? It's a programming >> language dedicated to job flows. BTW, I am happy with jcl... >> >> ITschak >> >> On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen wrote: >> >> > 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 >> > >> > Clem Clarke wrote on 07/10/2018 08:33 PM: >> > > 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=* >> > > //INTRANSDD 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) >> > > //SORTOUTDD 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) >> > > //MASTOUTDD DSN=PAYROLL.MASTER(+1),DISP=(NEW,PASS), >> > > //DCB=(RECFM=VB,LRECL=200,BLKSIZE=13030), >> > > //SPACE=(CYL,(10,10),RLSE), >> > > //UNIT=SYSDA,VOL=S
Re: REXX as JCL replacement
There is a GDGBIAS=JOB | STEP parm on the JOB statement in z/OS
2.3.
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
"IBM Mainframe Discussion List" wrote on
07/11/2018 03:35:00 PM:
> From: "Tony Thigpen"
> To: IBM-MAIN@LISTSERV.UA.EDU
> Date: 07/11/2018 04:39 PM
> Subject: Re: REXX as JCL replacement
> Sent by: "IBM Mainframe Discussion List"
>
> Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
> created in a step, it becomes the current GDG for all following steps.
> So, following steps don't need to reference +1, then require a change
> during a restart.
>
> It part of the difference that z/OS reads the whole job in then
> allocates everything where as z/VSE only reads the following JCL after
> the previous step has completed.
>
> Tony Thigpen
>
> John McKown wrote on 07/11/2018 01:30 PM:
> > On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
> > wrote:
> >
> > I, like many here, am old enough to remember how much of a PITA
> > it was to restart a job when a step failed for some reason. Mainly
deleting
> > datasets, but also changing GDG relative generation numbers if the
restart
> > is after the step which created the new GDG which is used in
subsequent
> > steps. {shudder}
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Yap. google "Work Flow Language (WFL) Programming Reference Manual pdf" to get the PDF version. Just performing a pentest for a UNISYS client in Europe and every-time i am surprised with the agility of it. ITschak On Wed, Jul 11, 2018 at 7:29 PM Seymour J Metz wrote: > Do you have a link to the WFL reference? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of ITschak Mugzach > Sent: Wednesday, July 11, 2018 6:20 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: REXX as JCL replacement > > Speaking of replacing JCL, how about unisys WFL? It's a programming > language dedicated to job flows. BTW, I am happy with jcl... > > ITschak > > On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen wrote: > > > 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 > > > > Clem Clarke wrote on 07/10/2018 08:33 PM: > > > 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=* > > > //INTRANSDD 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) > > > //SORTOUTDD 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) > > > //MASTOUTDD 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' > > > > > > > > > > > > Andrew Rowley wrote: > > >> On 9/07/2018 10:46 PM, Hobart Spitz wrote: > > >>> > > >>> Basically, JCL is so far fr
Re: REXX as JCL replacement
Restarts with GDGs is one thing z/VSE is much better at. Once a GDG is
created in a step, it becomes the current GDG for all following steps.
So, following steps don't need to reference +1, then require a change
during a restart.
It part of the difference that z/OS reads the whole job in then
allocates everything where as z/VSE only reads the following JCL after
the previous step has completed.
Tony Thigpen
John McKown wrote on 07/11/2018 01:30 PM:
On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
wrote:
I, like many here, am old enough to remember how much of a PITA
it was to restart a job when a step failed for some reason. Mainly deleting
datasets, but also changing GDG relative generation numbers if the restart
is after the step which created the new GDG which is used in subsequent
steps. {shudder}
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 11 Jul 2018 14:09:16 -0500, Tom Marchant wrote: >> >>>I don't like JCL, but I don't see any way forward other than incremental >>>improvements. >>> >>Business case for those? And trimming the whiskers from JCL would >>create compatibility problems for users who have come to depend on >>them, even if only as circumventions. > >An example of an incremental improvement is IF/THEN/ELSE/ENDIF. > If only the developers had been conscientious: //NAME JOB ... //* "IF" *should* not occur before the first EXEC. Accepted with no warning. //MAYBE IFFALSE THEN /* Unsupported syntax, accepted with no warning! */ //STEP1 EXEC PGM=IEFBR14 /* This step is executed, but ...*/ //STEP2 EXEC PGM=IEFBR14 /* ... this step is skipped. WTF!? */ //MAYBE ENDIF /* Label *should* be unique. No warning. */ ... the face of JCL bcomes increasingly unkempt. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
My thinking was that part of the parallel allocation would be to free existing allocations, but there might be issues with that. If there is no business case for an incremental improvement than there certainly isn't one for a total replacement. Given the control block structure for starting a new address space and allocating its data sets, that would be a massive effort. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 11, 2018 2:51 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote: >You keep missing the point that REXX does not currently provide the >serialization >that is available through JCL. Rewriting the job as a REXX script that does >not do >the necessary serialization is a CLM. > ??CLM?? >That's why I suggested a parallel allocation facility usable from REXX. > In order to avoid deadlocks, that parallel allocation facility must be invoked only once, and before any other SYSDSN ENQs are extant. There might be a way: launch the Rexx script from Unix System Services. Better yet, support //SYSEXEC DD PATH='/...' so no static ENQs are needed. RFE material? >I don't like JCL, but I don't see any way forward other than incremental >improvements. > Business case for those? And trimming the whiskers from JCL would create compatibility problems for users who have come to depend on them, even if only as circumventions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 11 Jul 2018 13:51:05 -0500, Paul Gilmartin wrote: >On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote: > >>I don't like JCL, but I don't see any way forward other than incremental >>improvements. >> >Business case for those? And trimming the whiskers from JCL would >create compatibility problems for users who have come to depend on >them, even if only as circumventions. An example of an incremental improvement is IF/THEN/ELSE/ENDIF. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Sorry John. I know how businesses work. My comment was rude, sarcastic, and uncalled for. I should not have sent it. 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 Wed, Jul 11, 2018 at 2:48 PM, John McKown wrote: > On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz wrote: > > > John; So the production schedules set policy in your shop. Do they pay > > the bills too? > > > > Well, they run the jobs which keep the company running which pays my > salary. But if you want who, at least in the past, sets policy -- it was > the end user departments. They demand, we supply. The most precious > employees are the sales agents. No sales, no money. No money, no company. > It runs down hill from there. I.e. the departments support the sales force. > We support the departments. So we are at the bottom of the support list. > > -- > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 11 Jul 2018 18:09:21 +, Seymour J Metz wrote: >You keep missing the point that REXX does not currently provide the >serialization >that is available through JCL. Rewriting the job as a REXX script that does >not do >the necessary serialization is a CLM. > ??CLM?? >That's why I suggested a parallel allocation facility usable from REXX. > In order to avoid deadlocks, that parallel allocation facility must be invoked only once, and before any other SYSDSN ENQs are extant. There might be a way: launch the Rexx script from Unix System Services. Better yet, support //SYSEXEC DD PATH='/...' so no static ENQs are needed. RFE material? >I don't like JCL, but I don't see any way forward other than incremental >improvements. > Business case for those? And trimming the whiskers from JCL would create compatibility problems for users who have come to depend on them, even if only as circumventions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, Jul 11, 2018 at 1:38 PM Hobart Spitz wrote: > John; So the production schedules set policy in your shop. Do they pay > the bills too? > Well, they run the jobs which keep the company running which pays my salary. But if you want who, at least in the past, sets policy -- it was the end user departments. They demand, we supply. The most precious employees are the sales agents. No sales, no money. No money, no company. It runs down hill from there. I.e. the departments support the sales force. We support the departments. So we are at the bottom of the support list. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
John; So the production schedules set policy in your shop. Do they pay the bills too? 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 Wed, Jul 11, 2018 at 2:09 PM, Seymour J Metz wrote: > You keep missing the point that REXX does not currently provide the > serialization that is available through JCL. Rewriting the job as a REXX > script that does not do the necessary serialization is a CLM. That's why I > suggested a parallel allocation facility usable from REXX. > > I don't like JCL, but I don't see any way forward other than incremental > improvements. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Hobart Spitz > Sent: Wednesday, July 11, 2018 1:30 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: REXX as JCL replacement > > Skip; > > What you say is true. Massive replacement would not be justified. No one > is advocating such an effort. > > What needs to happen is for people to stop writing new JCL (or copying old > JCL, especially the bad stuff) and work as if it were the 21st century. > > In addition to not writing new JCL, there are some prime replacement > candidates to consider now: > >- PROCs are executed frequently. The improvements, whether functional >or performance, would be multiplied across all JOBs that EXECute those >PROCs. >- >- PROCs that only use utilities and/or batch TSO, combining all into one >step. >- Replacing frequently executed IEFBR14s that sometimes create a dataset >just to delete it, or that delete perfectly good dataset. Are all those >ENQs, RESERVEs, catalog searches and updates, and VTOC searches and > updates >really worth it just because DISP=MOD can't change DCB info? >- JOBs with complex parameter or restart requirements. >- JOBs that run frequently. >- JOBs that need special serialization. Invoke the program(s) in a REXX >loop. Serialization problems gone. >- Applications that do updates primarily in DB2 and/or PDSEs. >- Applications that need more generalized automation. Drop the >expensive third-party software. You play by your rules, not someone > else's. >- Any process that has complex or hard to maintain JCL. > > There are more. > > Once you understand the benefits, to vendors and customers, the choice is > clear. > > 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 Wed, Jul 11, 2018 at 1:00 PM, Jesse 1 Robinson > > wrote: > > > This thread is entertaining but largely cherry-pie-in-the-sky. While it > > might be a nice exercise for sysprogs and architects, what's missing so > far > > is a compelling business case to justify the pain and agony of actually > > replacing JCL in a real world environment. For a mature shop with > thousands > > of jobs to manage--most of which work very well most of the time--it > would > > be a very hard sell to justify resources to build a replacement that > would > > mostly work better most of the time. > > > > I'm reminded of the old saw about teaching a dog to walk on its hind > legs. > > What's compelling is not that the dog does it well but merely that she > can > > walk that way at all. Worth maybe admission to a vaudeville show but not > a > > reason to turn your life upside down. > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > > Behalf Of Hobart Spitz > > Sent: Wednesday, July 11, 2018 9:42 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: REXX as JCL replacement > > > > Gil wrote: > > >SORT is quasi-batch: > > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can > run > > SORT(s) to completion completely independently of the main pipe, to name > > just tw
Re: REXX as JCL replacement
You keep missing the point that REXX does not currently provide the serialization that is available through JCL. Rewriting the job as a REXX script that does not do the necessary serialization is a CLM. That's why I suggested a parallel allocation facility usable from REXX. I don't like JCL, but I don't see any way forward other than incremental improvements. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Hobart Spitz Sent: Wednesday, July 11, 2018 1:30 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement Skip; What you say is true. Massive replacement would not be justified. No one is advocating such an effort. What needs to happen is for people to stop writing new JCL (or copying old JCL, especially the bad stuff) and work as if it were the 21st century. In addition to not writing new JCL, there are some prime replacement candidates to consider now: - PROCs are executed frequently. The improvements, whether functional or performance, would be multiplied across all JOBs that EXECute those PROCs. - - PROCs that only use utilities and/or batch TSO, combining all into one step. - Replacing frequently executed IEFBR14s that sometimes create a dataset just to delete it, or that delete perfectly good dataset. Are all those ENQs, RESERVEs, catalog searches and updates, and VTOC searches and updates really worth it just because DISP=MOD can't change DCB info? - JOBs with complex parameter or restart requirements. - JOBs that run frequently. - JOBs that need special serialization. Invoke the program(s) in a REXX loop. Serialization problems gone. - Applications that do updates primarily in DB2 and/or PDSEs. - Applications that need more generalized automation. Drop the expensive third-party software. You play by your rules, not someone else's. - Any process that has complex or hard to maintain JCL. There are more. Once you understand the benefits, to vendors and customers, the choice is clear. 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 Wed, Jul 11, 2018 at 1:00 PM, Jesse 1 Robinson wrote: > This thread is entertaining but largely cherry-pie-in-the-sky. While it > might be a nice exercise for sysprogs and architects, what's missing so far > is a compelling business case to justify the pain and agony of actually > replacing JCL in a real world environment. For a mature shop with thousands > of jobs to manage--most of which work very well most of the time--it would > be a very hard sell to justify resources to build a replacement that would > mostly work better most of the time. > > I'm reminded of the old saw about teaching a dog to walk on its hind legs. > What's compelling is not that the dog does it well but merely that she can > walk that way at all. Worth maybe admission to a vaudeville show but not a > reason to turn your life upside down. > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Hobart Spitz > Sent: Wednesday, July 11, 2018 9:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: REXX as JCL replacement > > Gil wrote: > >SORT is quasi-batch: > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run > SORT(s) to completion completely independently of the main pipe, to name > just two possibilities. The terminology in the PIPElines documentation is > "delaying records". Most built-in filters don't delay records, others > might delay some records some of the time, and others, like SORT delay, of > necessity, all records. Any filter that has to hold on to a record and > "think about it" before producing the corresponding result is said to > "delay the record". > > Any sequence of filters, each of which don't delay the record, when > combined in a single stream, will not delay the record. So much of the > time, you don't have or don't care about record delay. > > Delaying records doesn't into play until you get into non-trivial > multiple-stream PIPElines, where you have split a data stream into two and > then later combine them. In order for the right records to arrive at the > desired time at the joining point, you may need to
Re: REXX as JCL replacement
I would include the caveat Even though it is available, do not use Nested procs. Trying to override a proc within a proc within a proc .. rarely succeeds. Lizette > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Hobart Spitz > Sent: Wednesday, July 11, 2018 10:30 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX as JCL replacement > > Skip; > > What you say is true. Massive replacement would not be justified. No one is > advocating such an effort. > > What needs to happen is for people to stop writing new JCL (or copying old > JCL, especially the bad stuff) and work as if it were the 21st century. > > In addition to not writing new JCL, there are some prime replacement > candidates to consider now: > >- PROCs are executed frequently. The improvements, whether functional >or performance, would be multiplied across all JOBs that EXECute those >PROCs. >- >- PROCs that only use utilities and/or batch TSO, combining all into one >step. >- Replacing frequently executed IEFBR14s that sometimes create a dataset >just to delete it, or that delete perfectly good dataset. Are all those >ENQs, RESERVEs, catalog searches and updates, and VTOC searches and > updates >really worth it just because DISP=MOD can't change DCB info? >- JOBs with complex parameter or restart requirements. >- JOBs that run frequently. >- JOBs that need special serialization. Invoke the program(s) in a REXX >loop. Serialization problems gone. >- Applications that do updates primarily in DB2 and/or PDSEs. >- Applications that need more generalized automation. Drop the >expensive third-party software. You play by your rules, not someone > else's. >- Any process that has complex or hard to maintain JCL. > > There are more. > > Once you understand the benefits, to vendors and customers, the choice is > clear. > > 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 Wed, Jul 11, 2018 at 1:00 PM, Jesse 1 Robinson > wrote: > > > This thread is entertaining but largely cherry-pie-in-the-sky. While > > it might be a nice exercise for sysprogs and architects, what's > > missing so far is a compelling business case to justify the pain and > > agony of actually replacing JCL in a real world environment. For a > > mature shop with thousands of jobs to manage--most of which work very > > well most of the time--it would be a very hard sell to justify > > resources to build a replacement that would mostly work better most of the > time. > > > > I'm reminded of the old saw about teaching a dog to walk on its hind legs. > > What's compelling is not that the dog does it well but merely that she > > can walk that way at all. Worth maybe admission to a vaudeville show > > but not a reason to turn your life upside down. > > . > > . > > J.O.Skip Robinson > > Southern California Edison Company > > Electric Dragon Team Paddler > > SHARE MVS Program Co-Manager > > 323-715-0595 Mobile > > 626-543-6132 Office ⇐=== NEW > > robin...@sce.com > > > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Hobart Spitz > > Sent: Wednesday, July 11, 2018 9:42 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: (External):Re: REXX as JCL replacement > > > > Gil wrote: > > >SORT is quasi-batch: > > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can > > run > > SORT(s) to completion completely independently of the main pipe, to > > name just two possibilities. The terminology in the PIPElines > > documentation is "delaying records". Most built-in filters don't > > delay records, others might delay some records some of the time, and > > others, like SORT delay, of necessity, all records. Any filter that > > has to hold on to a record and "think about it" before producing the > > corresponding result is said to "delay the record". > > > > Any sequence of filters, each of which don't delay the record, when > > combined in a single stream, will not delay the record. So much of > > the time, you don't have or don't care about record delay. > > > > Delaying records doesn't into play until you get in
Re: REXX as JCL replacement
On Wed, Jul 11, 2018 at 12:01 PM Jesse 1 Robinson
wrote:
> This thread is entertaining but largely cherry-pie-in-the-sky. While it
> might be a nice exercise for sysprogs and architects, what's missing so far
> is a compelling business case to justify the pain and agony of actually
> replacing JCL in a real world environment. For a mature shop with thousands
> of jobs to manage--most of which work very well most of the time--it would
> be a very hard sell to justify resources to build a replacement that would
> mostly work better most of the time.
>
I agree. If whatever it is does not have something to do automated restart
similar to what I'm used to with CA-7, the production schedulers would
likely kill any programmer who tried to use it to run something in
production. I, like many here, am old enough to remember how much of a PITA
it was to restart a job when a step failed for some reason. Mainly deleting
datasets, but also changing GDG relative generation numbers if the restart
is after the step which created the new GDG which is used in subsequent
steps. {shudder}
>
> I'm reminded of the old saw about teaching a dog to walk on its hind legs.
> What's compelling is not that the dog does it well but merely that she can
> walk that way at all. Worth maybe admission to a vaudeville show but not a
> reason to turn your life upside down.
> .
> .
> J.O.Skip Robinson
> Southern California Edison Company
> Electric Dragon Team Paddler
> SHARE MVS Program Co-Manager
> 323-715-0595 Mobile
> 626-543-6132 Office ⇐=== NEW
> robin...@sce.com
--
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Skip; What you say is true. Massive replacement would not be justified. No one is advocating such an effort. What needs to happen is for people to stop writing new JCL (or copying old JCL, especially the bad stuff) and work as if it were the 21st century. In addition to not writing new JCL, there are some prime replacement candidates to consider now: - PROCs are executed frequently. The improvements, whether functional or performance, would be multiplied across all JOBs that EXECute those PROCs. - - PROCs that only use utilities and/or batch TSO, combining all into one step. - Replacing frequently executed IEFBR14s that sometimes create a dataset just to delete it, or that delete perfectly good dataset. Are all those ENQs, RESERVEs, catalog searches and updates, and VTOC searches and updates really worth it just because DISP=MOD can't change DCB info? - JOBs with complex parameter or restart requirements. - JOBs that run frequently. - JOBs that need special serialization. Invoke the program(s) in a REXX loop. Serialization problems gone. - Applications that do updates primarily in DB2 and/or PDSEs. - Applications that need more generalized automation. Drop the expensive third-party software. You play by your rules, not someone else's. - Any process that has complex or hard to maintain JCL. There are more. Once you understand the benefits, to vendors and customers, the choice is clear. 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 Wed, Jul 11, 2018 at 1:00 PM, Jesse 1 Robinson wrote: > This thread is entertaining but largely cherry-pie-in-the-sky. While it > might be a nice exercise for sysprogs and architects, what's missing so far > is a compelling business case to justify the pain and agony of actually > replacing JCL in a real world environment. For a mature shop with thousands > of jobs to manage--most of which work very well most of the time--it would > be a very hard sell to justify resources to build a replacement that would > mostly work better most of the time. > > I'm reminded of the old saw about teaching a dog to walk on its hind legs. > What's compelling is not that the dog does it well but merely that she can > walk that way at all. Worth maybe admission to a vaudeville show but not a > reason to turn your life upside down. > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Hobart Spitz > Sent: Wednesday, July 11, 2018 9:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: REXX as JCL replacement > > Gil wrote: > >SORT is quasi-batch: > A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run > SORT(s) to completion completely independently of the main pipe, to name > just two possibilities. The terminology in the PIPElines documentation is > "delaying records". Most built-in filters don't delay records, others > might delay some records some of the time, and others, like SORT delay, of > necessity, all records. Any filter that has to hold on to a record and > "think about it" before producing the corresponding result is said to > "delay the record". > > Any sequence of filters, each of which don't delay the record, when > combined in a single stream, will not delay the record. So much of the > time, you don't have or don't care about record delay. > > Delaying records doesn't into play until you get into non-trivial > multiple-stream PIPElines, where you have split a data stream into two and > then later combine them. In order for the right records to arrive at the > desired time at the joining point, you may need to take record delay into > account. This is something that is impossible in UNIX (at this time), > because UNIX piping data flow is not deterministic. > > Beginning pipers don't usually run into the issue. For one, there is so > much you can do with REXX and single stream PIPElines. For another, > multi-stream PIPElines require a small additional level of knowledge > concerning functionality and syntax. Melinda Varian has written some > excellent papers and talks on PIPElines. She was a long time advocate and > champion of PIPElines, especially under z/VM and CMS. You can find her > papers and more at &g
Re: REXX as JCL replacement
Do you have a link to the WFL reference? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of ITschak Mugzach Sent: Wednesday, July 11, 2018 6:20 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement Speaking of replacing JCL, how about unisys WFL? It's a programming language dedicated to job flows. BTW, I am happy with jcl... ITschak On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen wrote: > 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 > > Clem Clarke wrote on 07/10/2018 08:33 PM: > > 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=* > > //INTRANSDD 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) > > //SORTOUTDD 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) > > //MASTOUTDD 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' > > > > > > > > Andrew Rowley wrote: > >> On 9/07/2018 10:46 PM, Hobart Spitz wrote: > >>> > >>> 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 hi
Re: REXX as JCL replacement
This thread is entertaining but largely cherry-pie-in-the-sky. While it might be a nice exercise for sysprogs and architects, what's missing so far is a compelling business case to justify the pain and agony of actually replacing JCL in a real world environment. For a mature shop with thousands of jobs to manage--most of which work very well most of the time--it would be a very hard sell to justify resources to build a replacement that would mostly work better most of the time. I'm reminded of the old saw about teaching a dog to walk on its hind legs. What's compelling is not that the dog does it well but merely that she can walk that way at all. Worth maybe admission to a vaudeville show but not a reason to turn your life upside down. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hobart Spitz Sent: Wednesday, July 11, 2018 9:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: REXX as JCL replacement Gil wrote: >SORT is quasi-batch: A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run SORT(s) to completion completely independently of the main pipe, to name just two possibilities. The terminology in the PIPElines documentation is "delaying records". Most built-in filters don't delay records, others might delay some records some of the time, and others, like SORT delay, of necessity, all records. Any filter that has to hold on to a record and "think about it" before producing the corresponding result is said to "delay the record". Any sequence of filters, each of which don't delay the record, when combined in a single stream, will not delay the record. So much of the time, you don't have or don't care about record delay. Delaying records doesn't into play until you get into non-trivial multiple-stream PIPElines, where you have split a data stream into two and then later combine them. In order for the right records to arrive at the desired time at the joining point, you may need to take record delay into account. This is something that is impossible in UNIX (at this time), because UNIX piping data flow is not deterministic. Beginning pipers don't usually run into the issue. For one, there is so much you can do with REXX and single stream PIPElines. For another, multi-stream PIPElines require a small additional level of knowledge concerning functionality and syntax. Melinda Varian has written some excellent papers and talks on PIPElines. She was a long time advocate and champion of PIPElines, especially under z/VM and CMS. You can find her papers and more at http://vm.marist.edu/~pipeline/ The author's edition, the primary source of PIPElines information, can be found at. http://www-01.ibm.com/support/docview.wss?uid=pub1sl26001805 You need only read the first few chapters before you will start drooling to have the product. No joke. You'll begin to realize how much your productivity has been hampered by not having better tools at your disposal. I capitalize PIPElines this way because, apparently, there is a UNIX pipe command which has no connection or similarity to the TSO/CMS product. 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 Wed, Jul 11, 2018 at 11:54 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote: > > >Using pipelines could require a lot of programming changes. > >Historically, programs tend to be designed to process batches, not > records. > > > >Most shops will not have the bodies to do the changes needed. > > > Many programs process data sequentially and are well suited to using > pipes, which merely bypass temporary files and require no other changes. > > In ancient, main-storage-constrained environments pipes might actually > degrade performance: having multiple programs co-resident caused > paging I/O that overwhelmed any benefit of less temp file I/O. > > SORT is (too) often given as an example of a pipe stage. It can be > inappropriate because SORT is quasi-batch: SORT can not write the > first record to SORTOUT until it reads the last record from SORTIN. > > >I like the idea of REXX as a JCL replacement. It can provide a lot > >better logic. I don't know that it will make many inroads due to lack > >of man-power, but it can be a meth
Re: REXX as JCL replacement
Gil wrote: >SORT is quasi-batch: A REXX filter using ADDPIPE, or a "sipping" filter using CALLPIPE, can run SORT(s) to completion completely independently of the main pipe, to name just two possibilities. The terminology in the PIPElines documentation is "delaying records". Most built-in filters don't delay records, others might delay some records some of the time, and others, like SORT delay, of necessity, all records. Any filter that has to hold on to a record and "think about it" before producing the corresponding result is said to "delay the record". Any sequence of filters, each of which don't delay the record, when combined in a single stream, will not delay the record. So much of the time, you don't have or don't care about record delay. Delaying records doesn't into play until you get into non-trivial multiple-stream PIPElines, where you have split a data stream into two and then later combine them. In order for the right records to arrive at the desired time at the joining point, you may need to take record delay into account. This is something that is impossible in UNIX (at this time), because UNIX piping data flow is not deterministic. Beginning pipers don't usually run into the issue. For one, there is so much you can do with REXX and single stream PIPElines. For another, multi-stream PIPElines require a small additional level of knowledge concerning functionality and syntax. Melinda Varian has written some excellent papers and talks on PIPElines. She was a long time advocate and champion of PIPElines, especially under z/VM and CMS. You can find her papers and more at http://vm.marist.edu/~pipeline/ The author's edition, the primary source of PIPElines information, can be found at. http://www-01.ibm.com/support/docview.wss?uid=pub1sl26001805 You need only read the first few chapters before you will start drooling to have the product. No joke. You'll begin to realize how much your productivity has been hampered by not having better tools at your disposal. I capitalize PIPElines this way because, apparently, there is a UNIX pipe command which has no connection or similarity to the TSO/CMS product. 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 Wed, Jul 11, 2018 at 11:54 AM, Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote: > > >Using pipelines could require a lot of programming changes. > >Historically, programs tend to be designed to process batches, not > records. > > > >Most shops will not have the bodies to do the changes needed. > > > Many programs process data sequentially and are well suited to using pipes, > which merely bypass temporary files and require no other changes. > > In ancient, main-storage-constrained environments pipes might actually > degrade performance: having multiple programs co-resident caused > paging I/O that overwhelmed any benefit of less temp file I/O. > > SORT is (too) often given as an example of a pipe stage. It can be > inappropriate because SORT is quasi-batch: SORT can not write the > first record to SORTOUT until it reads the last record from SORTIN. > > >I like the idea of REXX as a JCL replacement. It can provide a lot > >better logic. I don't know that it will make many inroads due to lack of > >man-power, but it can be a method to the future. > > > >One of our staff looked seriously at JOL and rejected it. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 11 Jul 2018 11:03:05 -0400, Tony Thigpen wrote: >Using pipelines could require a lot of programming changes. >Historically, programs tend to be designed to process batches, not records. > >Most shops will not have the bodies to do the changes needed. > Many programs process data sequentially and are well suited to using pipes, which merely bypass temporary files and require no other changes. In ancient, main-storage-constrained environments pipes might actually degrade performance: having multiple programs co-resident caused paging I/O that overwhelmed any benefit of less temp file I/O. SORT is (too) often given as an example of a pipe stage. It can be inappropriate because SORT is quasi-batch: SORT can not write the first record to SORTOUT until it reads the last record from SORTIN. >I like the idea of REXX as a JCL replacement. It can provide a lot >better logic. I don't know that it will make many inroads due to lack of >man-power, but it can be a method to the future. > >One of our staff looked seriously at JOL and rejected it. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
It may be a long, slow process, generally and/or at some sites, but if
enough people do it, JCL will become the exception. IBM and site
management will get it, and additional needed tools/solutions or something
even better will be made available. Eventually.
Try it. Use what works. Refine what doesn't.
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 Wed, Jul 11, 2018 at 11:03 AM, Tony Thigpen wrote:
> Using pipelines could require a lot of programming changes. Historically,
> programs tend to be designed to process batches, not records.
>
> Most shops will not have the bodies to do the changes needed.
>
> I like the idea of REXX as a JCL replacement. It can provide a lot better
> logic. I don't know that it will make many inroads due to lack of
> man-power, but it can be a method to the future.
>
> One of our staff looked seriously at JOL and rejected it.
>
> Tony Thigpen
>
> Hobart Spitz wrote on 07/11/2018 08:37 AM:
>
>> 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.
>>
>> On Wed, Jul 11, 2018 at 6:40 AM, David Crayford
>> wrote:
>>
>> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>>>
>>> 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
>>>
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>>
>>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>>
>>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Using pipelines could require a lot of programming changes.
Historically, programs tend to be designed to process batches, not records.
Most shops will not have the bodies to do the changes needed.
I like the idea of REXX as a JCL replacement. It can provide a lot
better logic. I don't know that it will make many inroads due to lack of
man-power, but it can be a method to the future.
One of our staff looked seriously at JOL and rejected it.
Tony Thigpen
Hobart Spitz wrote on 07/11/2018 08:37 AM:
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.
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford wrote:
On 11/07/2018 7:19 AM, Clem Clarke wrote:
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
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
> Resistance to replacing JCL comes from the fact that "everybody knows JCL"
I haven't seen resistance to replacing JCL, just resistance to removing
functionality and doubt as to feasibility. So far nothing that has been
proposed actually does what JCL does.
That said, there's lots of room for improvement.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Hobart Spitz
Sent: Wednesday, July 11, 2018 8:37 AM
To: IBM-MAIN@listserv.ua.edu
Subject: Re: REXX as JCL replacement
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.
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford wrote:
> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>
>> 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
>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford wrote: > 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. > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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.
On Wed, Jul 11, 2018 at 6:40 AM, David Crayford wrote:
> On 11/07/2018 7:19 AM, Clem Clarke wrote:
>
>> 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
>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On 11/07/2018 7:19 AM, Clem Clarke wrote: 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 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Speaking of replacing JCL, how about unisys WFL? It's a programming language dedicated to job flows. BTW, I am happy with jcl... ITschak On Wed, Jul 11, 2018 at 12:09 PM Tony Thigpen wrote: > 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 > > Clem Clarke wrote on 07/10/2018 08:33 PM: > > 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=* > > //INTRANSDD 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) > > //SORTOUTDD 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) > > //MASTOUTDD 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' > > > > > > > > Andrew Rowley wrote: > >> On 9/07/2018 10:46 PM, Hobart Spitz wrote: > >>> > >>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >
Re: REXX as JCL replacement
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 Clem Clarke wrote on 07/10/2018 08:33 PM: 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' Andrew Rowley wrote: On 9/07/2018 10:46 PM, Hobart Spitz wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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' Andrew Rowley wrote: On 9/07/2018 10:46 PM, Hobart Spitz wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
Paul Gilmartin wrote: On Thu, 5 Jul 2018 14:23:35 -0400, Hobart Spitz wrote: 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. 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. ... 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 zMan wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 suhr...@gmail.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of David Crayford Sent: Monday, July 9, 2018 21:32 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement On 10/07/2018 7:15 AM, Andrew Rowley wrote: > On 9/07/2018 10:46 PM, Hobart Spitz wrote: >> >> 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! > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
> 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 on behalf of Ward Able, Grant Sent: Tuesday, July 10, 2018 5:12 AM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: 09 July 2018 16:10 To: IBM-MAIN@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 on behalf of Hobart Spitz Sent: Monday, July 9, 2018 8:46 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement Ward wrote: >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 appli
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: 09 July 2018 16:10 To: IBM-MAIN@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 on behalf of Hobart Spitz Sent: Monday, July 9, 2018 8:46 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement Ward wrote: >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 p
Re: REXX as JCL replacement
On 10/07/2018 7:15 AM, Andrew Rowley wrote: On 9/07/2018 10:46 PM, Hobart Spitz wrote: 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! 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, 9 Jul 2018 16:45:00 -0700, Charles Mills wrote: >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. On Mon, 9 Jul 2018 20:11:17 -0400, Steve Smith wrote: >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 On Mon, Jul 9, 2018 at 7:15 PM, Andrew Rowley wrote: > On 9/07/2018 10:46 PM, Hobart Spitz wrote: > >> >> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley Sent: Monday, July 9, 2018 4:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement On 9/07/2018 10:46 PM, Hobart Spitz wrote: > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On 9/07/2018 10:46 PM, Hobart Spitz wrote: 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, 9 Jul 2018 15:20:07 -0400, Hobart Spitz wrote: >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. >For example (untested): > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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. If you don't have REXXTRY, you can find the source on the web. I
would recommend one of the IBM versions.
For example (untested):
1. *//MYJOBNAM JOB (acct),'M.E.SMITH',MSGCLASS=t,...*
2. *// JCLLIB ORDER=(MY.JCL.LIB) Optional*
3. *// EXEC TSO,CMD=REXXTRY*
4. *//SYSTSIN DD * Recommended DD to avoid conflicts with SYSIN
use.*
5. *Trace = "e" /* Unique to REXXTRY. Show error commands. You may
prefer "c". */*
6. *"profile"*
7. *call outtrap "Lines."*
8. *"st myjobname"*
9. *call outtrap "off"*
10. *parse var Lines.1 "(" JESNum ")" /* cutting some corners here in
interest of brevity */*
11. *"%myrexpgm"*
12. *OutDSN = "out.data(results)"*
13. *DSStat = sysdsn(OutDSN)*
14. *if DSStat == "OK" | DSStat == "MEMBER NOT FOUND" then **DSOptions =
"shr"*
15. *if DSStat == "DATASET NOT FOUND" then **DSOptions = "new
catalog cyl space(10 10) dsntype(library)"*
16. *if var("DSOptions") == "LIT" then do;** say time() Lines.1 OutDSN
"-" DSStat; **exit 20; **end*
17. *"alloc reuse dd(sysut2) dsn("OutDSN")" DSOptions*
18. *if RC <> 0 then exit RC*
19. *"alloc reuse dd(sysin) dummy"*
20. *"alloc reuse dd(sysut1) shr dsn('my.in.data')"*
21. *"call *(iebgener)" /* Trace = "e" reports failures; GENER stops if
SYSIN/SYSUT1 missing/invalid. */*
22. *"free dd(sysut2, sysin, sysut1)"*
23. *//*
Here we can use SHR with our output PDSE if it already exists.
You must put ALLOCs, TSO CALLs, FREEs, and any other commands with
parentheses or characters that REXX is sensitive to, in quotes or quotation
marks. Quotation marks ( " ) are prefered if you have fully qualified
dataset names with quotes. See line 20.
Lines 12 thru 18 could form the basis of a common, external routine, since
it may be needed often.
Personally, I think this approach is so much better that I might set
REXXTRY as the default &CMD value in the PROC. On the other hand, you
don't have multil-line commands, continuations, the ability to supply
internal routines or SIGNAL handlers, so at some point it becomes
preferable to make a long sequence of commands into a program of its own.
Maybe this is what a JCL replacement could look like. Add in some commands
for compatibility (e.g. JCL DD, JCL STEPEXEC, JCL SET, etc.), and things
look rosier and practical.
Caution: DD DDNAME=... and "alloc ddname(...)" are two completely
different animals.
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 9, 2018 at 12:56 PM, Steve Smith wrote:
> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On 7/9/2018 8:09 AM, Seymour J Metz wrote: 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..." https://youtu.be/8c0_Lzb1CJw?t=4735 -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 on behalf of Hobart Spitz Sent: Monday, July 9, 2018 12:11 PM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz wrote: > 1. I don't recall anybody on IBM-MAIN claims that JCL is good. > There were such statements as "I like JCL", or similar. > > 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. > > 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. > > 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. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Hobart Spitz > Sent: Monday, July 9, 2018 8:46 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: REXX as JCL replacement > > Ward wrote: > >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 acti
Re: REXX as JCL replacement
On Mon, Jul 9, 2018 at 11:12 AM Hobart Spitz wrote: > On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz wrote: > > > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, Jul 9, 2018 at 11:09 AM, Seymour J Metz wrote: > 1. I don't recall anybody on IBM-MAIN claims that JCL is good. > There were such statements as "I like JCL", or similar. > > 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. > > 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. > > 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. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Hobart Spitz > Sent: Monday, July 9, 2018 8:46 AM > To: IBM-MAIN@listserv.ua.edu > Subject: Re: REXX as JCL replacement > > Ward wrote: > >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 dataset
Re: REXX as JCL replacement
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 on behalf of Hobart Spitz Sent: Monday, July 9, 2018 8:46 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: REXX as JCL replacement Ward wrote: >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 li
Re: REXX as JCL replacement
On Mon, 9 Jul 2018 08:46:56 -0400, Hobart Spitz wrote: > >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. >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. >... >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. > Data set aliases break this assumption. > 3. ENQs are obtained on all datasets. > But for ALIAS names, not RELATED names. > 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. >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. :-) ) > However effective this is, I doubt that it's practical. I suspect you feel likewise. > - 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. > - 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? > - Something else. > ??? Another exercise for the reader? >... > 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. > ... and has a steep learning curve. > ITYM "shallow" learning curve. Proficiency is acquired slowly. > 4. JCL is a barrier to attracting new business to z/OS. Bad news if you > are a vendor. > Yes. > 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? > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
control cards will mostly have to stay, and you will need a TSO batch step. I recommend a PROC like this. *//TSOPROC 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=SYSINIn 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. On Wed, Jul 4, 2018 at 3:53 AM, Ward Able, Grant wrote: > I seldom post here, but have been intrigued by this thread. > > What are the problems (perceived or real) that will be resolved by > replacing JCL with REXX? > > > > Regards – Grant. > > In theory, there's no difference between theory and practice. In practice, > there is. > > There is no such thing as the Cloud. It is just somebody else’s computer. > > If you don't have time to do it right, when will you have the time to do > it over? - John Wooden > > > DTCC Internal (Green) > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: 03 July 2018 21:39 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX as JCL replacement > > ATTENTION! This email originated outside of DTCC; exercise caution. > > > On Tue, 3 Jul 2018 15:39:40 -0400, Tony Thigpen wrote: > > >PARSE SOURCE on VSE returns: > >VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC TESTREXX VSE > >VSE ? > > > So it would be practical to multipath for compatibility. > > >VSE does not have pipelines. > > > z/OS barely has Pipelines. An obsolete version. And hard to order. > > For more than you want to know about Rexx (in)compatibility, see Dave > Alcocks http://planetmvs.com/rexxanywhere/index.html > > OK. Thanks. Comparing z/VSE and Z/OS ADDRESS environments, I see: > >z/VSE z/OS > > Ref.SC33-6642-10 SA32-0972-30 > > LINKLike 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. > auto
Re: REXX as JCL replacement
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 on behalf of
Charles Mills
Sent: Thursday, July 5, 2018 4:29 PM
To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf
Of Hobart Spitz
Sent: Thursday, July 5, 2018 11:24 AM
To: IBM-MAIN@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 <> 0parse 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 thendo iTry = 1 to 5 while
Status = "DATASET UNAVAILABLE"say time() DSN "unavailable,
retrying."/* Wou
Re: REXX as JCL replacement
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 on behalf of Charles Mills Sent: Thursday, July 5, 2018 6:35 PM To: IBM-MAIN@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-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, July 5, 2018 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement On Thu, 5 Jul 2018 13:29:01 -0700, Charles Mills wrote: >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." > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, July 5, 2018 2:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement On Thu, 5 Jul 2018 13:29:01 -0700, Charles Mills wrote: >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." > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Thu, 5 Jul 2018 13:29:01 -0700, Charles Mills wrote: >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." > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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-MAIN@LISTSERV.UA.EDU] On Behalf
Of Hobart Spitz
Sent: Thursday, July 5, 2018 11:24 AM
To: IBM-MAIN@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 <> 0parse 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 thendo 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
thennopwhen subword(Status, 2) = "NOT FOUND" & *
*wordpos(BeforeDisp, "NEW MOD") then*
*nopotherwise /* Status incompatible with BeforeDisp,
or other error. */say "Attempting" arg(iA)", status"
Status"." leave iAend "allocate re
Re: REXX as JCL replacement
On Thu, 5 Jul 2018 14:23:35 -0400, Hobart Spitz wrote: >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. >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, ... > Why would one want to? > ... and the foreground scripting languages can be useful in >background, but aren't. ... > There's IRXJCL and IKJEFT*. > ... 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. >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. >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. >*/* 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 <> 0parse 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 thendo 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
thennopwhen subword(Status, 2) = "NOT FOUND" & *
*wordpos(BeforeDisp, "NEW MOD") then*
*nopotherwise /* Status incompatible with BeforeDisp,
or other error. */say "Attempting" arg(iA)", status"
Status"." leave iAend "allocate reuse
file("DDname")" BeforeDisp NormDisp "dataset("DSNAlloced.iA = (RC = 0)
end iAif iA > arg() then /* Success */exit 0/* Failure */do iA2 = 1
to iAif 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.
On Wed, Jul 4, 2018 at 9:14 PM, zMan wrote:
> >
> > >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
Re: REXX as JCL replacement
> > >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 Charles Mills wrote: 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Wednesday, July 4, 2018 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Wed, 4 Jul 2018 11:21:27 -0500, Joel C. Ewing wrote: >On 07/04/2018 02:53 AM, Ward Able, Grant wrote: >> I seldom post here, but have been intrigued by this thread. >> >> What are the problems (perceived or real) that will be resolved by replacing >> JCL with REXX? >> 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.) >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 ---
Re: REXX as JCL replacement
> 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-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel C. Ewing Sent: Wednesday, July 4, 2018 9:21 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On 07/04/2018 02:53 AM, Ward Able, Grant wrote: > I seldom post here, but have been intrigued by this thread. > > What are the problems (perceived or real) that will be resolved by replacing > JCL with REXX? > > > > Regards – Grant. > > In theory, there's no difference between theory and practice. In practice, > there is. > > There is no such thing as the Cloud. It is just somebody else’s computer. > > If you don't have time to do it right, when will you have the time to do it > over? - John Wooden > > > DTCC Internal (Green) > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: 03 July 2018 21:39 > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: REXX as JCL replacement > > ATTENTION! This email originated outside of DTCC; exercise caution. > > > On Tue, 3 Jul 2018 15:39:40 -0400, Tony Thigpen wrote: > >> PARSE SOURCE on VSE returns: >> VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC TESTREXX VSE >> VSE ? >> > So it would be practical to multipath for compatibility. > >> VSE does not have pipelines. >> > z/OS barely has Pipelines. An obsolete version. And hard to order. > > For more than you want to know about Rexx (in)compatibility, see Dave Alcocks > http://planetmvs.com/rexxanywhere/index.html > > OK. Thanks. Comparing z/VSE and Z/OS ADDRESS environments, I see: > >z/VSE z/OS > > Ref.SC33-6642-10 SA32-0972-30 > > LINKLike 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
Re: REXX as JCL replacement
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: 03 July 2018 21:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: REXX as JCL replacement ATTENTION! This email originated outside of DTCC; exercise caution. On Tue, 3 Jul 2018 15:39:40 -0400, Tony Thigpen wrote: >PARSE SOURCE on VSE returns: >VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC TESTREXX VSE >VSE ? > So it would be practical to multipath for compatibility. >VSE does not have pipelines. > z/OS barely has Pipelines. An obsolete version. And hard to order. For more than you want to know about Rexx (in)compatibility, see Dave Alcocks http://planetmvs.com/rexxanywhere/index.html OK. Thanks. Comparing z/VSE and Z/OS ADDRESS environments, I see: z/VSE z/OS Ref.SC33-6642-10 SA32-0972-30 LINKLike 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 lists...@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Tue, 3 Jul 2018 15:39:40 -0400, Tony Thigpen wrote: >PARSE SOURCE on VSE returns: >VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC >TESTREXX VSE VSE ? > So it would be practical to multipath for compatibility. >VSE does not have pipelines. > z/OS barely has Pipelines. An obsolete version. And hard to order. For more than you want to know about Rexx (in)compatibility, see Dave Alcocks http://planetmvs.com/rexxanywhere/index.html OK. Thanks. Comparing z/VSE and Z/OS ADDRESS environments, I see: z/VSE z/OS Ref.SC33-6642-10 SA32-0972-30 LINKLike 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
PARSE SOURCE on VSE returns: VSE COMMAND TESTREXX PROC IPLLIB.VSE2PDF1.TESTREXX.PROC TESTREXX VSE VSE ? VSE does not have pipelines. Tony Thigpen Paul Gilmartin wrote on 07/03/2018 03:17 PM: On Tue, 3 Jul 2018 13:25:40 -0400, Hobart Spitz wrote: 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. 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. On Tue, 3 Jul 2018 13:39:49 -0400, Tony Thigpen wrote: 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? 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Tue, 3 Jul 2018 13:25:40 -0400, Hobart Spitz wrote: >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. > 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. On Tue, 3 Jul 2018 13:39:49 -0400, Tony Thigpen wrote: >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? >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 Paul Gilmartin wrote on 07/03/2018 12:23 PM: On 2018-07-03, at 08:58:26, Tony Thigpen wrote: *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? We also have ways to provide SYSIN and capture SYSLST: 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. Seymour J Metz wrote on 07/03/2018 10:32 AM: When you reinvent the wheel, please make them round. A procedural replacement for JCL has all sorts of issues, regardless of syntax. Instead, why not 1. Enhance Dynalloc to have a parallel allocation function. 2. Enhance IRXJCL to allow a script in a sequential dataset. 3. Enhance REXX to support parallel allocation. The installation could then provide custom procedures for invoking IRXJCL -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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, < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On 2018-07-03, at 08:58:26, Tony Thigpen wrote: > > > *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? > > > We also have ways to provide SYSIN and capture SYSLST: > > 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. > > > > Seymour J Metz wrote on 07/03/2018 10:32 AM: > >> When you reinvent the wheel, please make them round. A procedural > replacement for JCL has all sorts of issues, regardless of syntax. Instead, > why not > >> 1. Enhance Dynalloc to have a parallel allocation function. > >> 2. Enhance IRXJCL to allow a script in a sequential dataset. > >> 3. Enhance REXX to support parallel allocation. > >> The installation could then provide custom procedures for invoking > IRXJCL > > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On 2018-07-03, at 08:58:26, Tony Thigpen wrote: > *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? > We also have ways to provide SYSIN and capture SYSLST: > 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. > Seymour J Metz wrote on 07/03/2018 10:32 AM: >> When you reinvent the wheel, please make them round. A procedural >> replacement for JCL has all sorts of issues, regardless of syntax. Instead, >> why not >> 1. Enhance Dynalloc to have a parallel allocation function. >> 2. Enhance IRXJCL to allow a script in a sequential dataset. >> 3. Enhance REXX to support parallel allocation. >> The installation could then provide custom procedures for invoking IRXJCL -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
*PLEASE* don't re-invent the wheel. z/VSE has had this for 15+ years. We
have had time to shake out the issues.
parm_value = ’this is a parameter string’
ADDRESS LINK ’TESTMODA’ parm_value
or
ADDRESS LINKPGM "PROGRAM p1 p2 ... pn"
We also have ways to provide SYSIN and capture SYSLST:
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
example (from book):
ARG file_name
CALL OUTTRAP idcams_output.
CALL REXXIPT idcams_input.
idcams_input.0 = 1
idcams_input.1 = ’LISTCAT CLUSTER’
ADDRESS LINK ’IDCAMS MARGINS(1 80)’
IF rc = 0
THEN CALL Print_Only_Lines_Including file_name
ELSE SAY ’IDCAMS LISTCAT fails with RC=’rc
EXIT
Print_Only_Lines_Including:
ARG search_name
DO line = 1 to idcams_output.0
IF WORDPOS(search_name,translate(idcams_output.line))¬=0
THEN SAY idcams_output.line
END
RETURN
Tony Thigpen
Seymour J Metz wrote on 07/03/2018 10:32 AM:
When you reinvent the wheel, please make them round. A procedural replacement
for JCL has all sorts of issues, regardless of syntax. Instead, why not
1. Enhance Dynalloc to have a parallel allocation function.
2. Enhance IRXJCL to allow a script in a sequential dataset.
3. Enhance REXX to support parallel allocation.
The installation could then provide custom procedures for invoking IRXJCL
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of Hobart
Spitz
Sent: Monday, July 2, 2018 2:37 PM
To: IBM-MAIN@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 <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
Oh my gosh, you would have to maintain JCL forever for that and a dozen
other reasons.
BUT! Conceivably ... conceivably ... you might stabilize it and do
everything new in Rexx going forward.
If the replacement had a superset of JCL function, providing a
JCL-to-replacement
translation utility would allow discarding direct support for JCL.
-Original Message-
From: John Melcher, Jr
Sent: Monday, July 2, 2018 10:46 AM
Once upon a time a LONG time ago this was a GUIDE requirement. It was
voted down due to the amount of automated systems that generated JCL.
You'd have to keep JCL, probably forever, because of those systems.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, July 3, 2018 7:33 AM To: IBM-MAIN@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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Discussion List on behalf of
Hobart Spitz
Sent: Monday, July 2, 2018 2:37 PM
To: IBM-MAIN@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 <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
>
> >Oh my gosh, you would have to maintain JCL forever for that and a dozen
> other reasons.
> >
> >BUT! Conceivably ... conceivably ... you might stabilize it and do
> everything new in Rexx going forward.
> >
> If the replacement had a superset of JCL function, providing a
> JCL-to-replacement
> translation utility would allow discarding direct support for JCL.
>
> >-Original Message-
> >From: John Melcher, Jr
> >Sent: Monday, July 2, 2018 10:46 AM
> >
> >Once upon a time a LONG time ago this was a GUIDE requirement. It was
> >voted down due to the amount of automated systems that generated JCL.
> >You'd have to keep JCL, probably forever, because of those systems.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, 2 Jul 2018 14:41:44 -0400, Steve Smith wrote: >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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 On 02/07/2018 19:41, Steve Smith wrote: > 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 < > 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: >> >>> Oh my gosh, you would have to maintain JCL forever for that and a dozen >> other reasons. >>> BUT! Conceivably ... conceivably ... you might stabilize it and do >> everything new in Rexx going forward. >> If the replacement had a superset of JCL function, providing a >> JCL-to-replacement >> translation utility would allow discarding direct support for JCL. >> >>> -Original Message- >>> From: John Melcher, Jr >>> Sent: Monday, July 2, 2018 10:46 AM >>> >>> Once upon a time a LONG time ago this was a GUIDE requirement. It was >>> voted down due to the amount of automated systems that generated JCL. >>> You'd have to keep JCL, probably forever, because of those systems. >> -- gil >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
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 < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: > > >Oh my gosh, you would have to maintain JCL forever for that and a dozen > other reasons. > > > >BUT! Conceivably ... conceivably ... you might stabilize it and do > everything new in Rexx going forward. > > > If the replacement had a superset of JCL function, providing a > JCL-to-replacement > translation utility would allow discarding direct support for JCL. > > >-Original Message- > >From: John Melcher, Jr > >Sent: Monday, July 2, 2018 10:46 AM > > > >Once upon a time a LONG time ago this was a GUIDE requirement. It was > >voted down due to the amount of automated systems that generated JCL. > >You'd have to keep JCL, probably forever, because of those systems. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [EXTERNAL] Re: REXX as JCL replacement
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) <
Mainframe Systems Programmer – RavenTek Solution Partners
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Hobart Spitz
Sent: Monday, July 02, 2018 1:37 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: REXX as JCL replacement
How about something like this?
Use REXX syntax and a JCL host command with JCL-like semantics:
/* REXX */
arg String /* From SUBMIT or start task command. */
"jcl job myjob: (acct),'john smith',class=t,msgclass=h,notify="userid()
"jcl exec pgm=myprog,parm="date("s")
"jcl sysprint: dd sysout=*"
"jcl sysin dd *"
"jcl data" String
...
The JCL host command could create the exact same control blocks as the
existing JCL statements today, but not begin execution. When the REXX exec
exited, ENQs would be processed as now, followed by the current processing,
including step execution, and cleanup. All exit/interfaces would be
preserved so that third-party software would still work unchanged.
OREXXMan
JCL is the buggy whip of 21st century computing. Stabilize it.
Put Pipelines in the z/OS base. Would you rather process data one
character at a time (Unix/C style), or one record at a time?
IBM has been looking for an HLL for program products; REXX is that language.
On Mon, Jul 2, 2018 at 2:26 PM, Paul Gilmartin <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
>
> >Oh my gosh, you would have to maintain JCL forever for that and a dozen
> other reasons.
> >
> >BUT! Conceivably ... conceivably ... you might stabilize it and do
> everything new in Rexx going forward.
> >
> If the replacement had a superset of JCL function, providing a
> JCL-to-replacement
> translation utility would allow discarding direct support for JCL.
>
> >-Original Message-
> >From: John Melcher, Jr
> >Sent: Monday, July 2, 2018 10:46 AM
> >
> >Once upon a time a LONG time ago this was a GUIDE requirement. It was
> >voted down due to the amount of automated systems that generated JCL.
> >You'd have to keep JCL, probably forever, because of those systems.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 <
000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote:
>
> >Oh my gosh, you would have to maintain JCL forever for that and a dozen
> other reasons.
> >
> >BUT! Conceivably ... conceivably ... you might stabilize it and do
> everything new in Rexx going forward.
> >
> If the replacement had a superset of JCL function, providing a
> JCL-to-replacement
> translation utility would allow discarding direct support for JCL.
>
> >-Original Message-
> >From: John Melcher, Jr
> >Sent: Monday, July 2, 2018 10:46 AM
> >
> >Once upon a time a LONG time ago this was a GUIDE requirement. It was
> >voted down due to the amount of automated systems that generated JCL.
> >You'd have to keep JCL, probably forever, because of those systems.
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REXX as JCL replacement
On Mon, 2 Jul 2018 11:10:31 -0700, Charles Mills wrote: >Oh my gosh, you would have to maintain JCL forever for that and a dozen other >reasons. > >BUT! Conceivably ... conceivably ... you might stabilize it and do everything >new in Rexx going forward. > If the replacement had a superset of JCL function, providing a JCL-to-replacement translation utility would allow discarding direct support for JCL. >-Original Message- >From: John Melcher, Jr >Sent: Monday, July 2, 2018 10:46 AM > >Once upon a time a LONG time ago this was a GUIDE requirement. It was >voted down due to the amount of automated systems that generated JCL. >You'd have to keep JCL, probably forever, because of those systems. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
