Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
I used a B6700 at University and I became a fan of WFL, Algol, DCAlgol and Espol (student). In fact I wrote a parser for a Linear Programming language using Algol. I actually designed the language using BNF and parsed the statements that way. The only alternatives I have found to Algol (Burroughs style) are PL1 and maybe Pascal. But then I have never programmed in C or C++ Can't beat WFL - JCL is so strict syntax wise. On Thu, Mar 21, 2019 at 5:37 AM Seymour J Metz wrote: > Burroughs had several product lines; only the B6500 line survives at > Unisys. The B2500 line had the sign to the left. The B6500 had the sign > bit to the left for packed and to the right for signed numeric character > data. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Discussion List on behalf > of Savor, Thomas (Alpharetta) > Sent: Wednesday, March 20, 2019 1:42 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL > replacement > > Many years ago when Converting a DDA system from Burroughs to IBM, > Burroughs packed fields had the annoying habit of putting the sign at the > beginning of the fieldinstead of the end of the field like IBM. > Made for pages and pages of "Move with Offsets" in the Assembler > programsCobol didn’t care for it at all. > > Does Burroughs still do that ?? > > Thanks, > > Tom Savor > > -- > 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
Burroughs had several product lines; only the B6500 line survives at Unisys. The B2500 line had the sign to the left. The B6500 had the sign bit to the left for packed and to the right for signed numeric character data. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Savor, Thomas (Alpharetta) Sent: Wednesday, March 20, 2019 1:42 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement Many years ago when Converting a DDA system from Burroughs to IBM, Burroughs packed fields had the annoying habit of putting the sign at the beginning of the fieldinstead of the end of the field like IBM. Made for pages and pages of "Move with Offsets" in the Assembler programsCobol didn’t care for it at all. Does Burroughs still do that ?? Thanks, Tom Savor -- 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
Many years ago when Converting a DDA system from Burroughs to IBM, Burroughs packed fields had the annoying habit of putting the sign at the beginning of the fieldinstead of the end of the field like IBM. Made for pages and pages of "Move with Offsets" in the Assembler programsCobol didn’t care for it at all. Does Burroughs still do that ?? Thanks, Tom Savor -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
I did write code for Jol to create VSE JCL. I never got to test it though. The original idea of Jol was to have a Universal Command Language running on MVS and VSE, and other systems. It does run on Windows, Linux and even OS/2, as well as Z/OS. You can read more at: http://start.oscar-jol.com/ Clem Clarke Seymour J Metz wrote: It's not at all unusual that when you have experience with multiple systems, you find features on each that you wish you had on the others, e.g., in TSO I miss XEDIT. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, July 10, 2018 11:58 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote: How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL probably are irrelevant. I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine that included essentially the entire Master Control Program (MCP) that ran on the bigger machines. I remember that Work Flow Language was considerably more powerful than JCL, but I don't remember any specifics. I had been working with JCL for a few years at the time. I have a vague recollection that there were a few things that you couldn't do in WFL that you could do in JCL. I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't find one, but I did find a 6700/7700 System Software Handbook that has a section on WFL. http://secure-web.cisco.com/1oaw3qgL4gjrPhX7F7mKUCWRYzVJCVNgBwvF4n69Tyh4AiTXZYpvdbYElQO_gQk39Aw8SKZL9EXHZxQC8j-HRQRZzE7dlu451IHUVHWRfCJtQ00yp5sP3tstyn70_nPF6jmBoZUYcr-9WsLkk3GQgxMPY6nEZ7ACnOrZvpA34fbcaetW1zYw5Vt6gheD3oNbMwgEhltw22YM32Lj5CJDN_QDcjNYf8R6VKTHVEi5KYN0IHZMPYXf6d4KjudGDEMh2PmecWl8oZZr2bOSkFLbzq-GZtvS0xmWFuKj3bPJz4GYa7E01_eypOi0haPjAeqCj29TtqDZUdB1Ll2lGlmMF1EAxNzR77A5iQsuvJgokfUnhlv2QGGJzURH-6JVXxr0GsisYrwaY1Mtu_nfA3YVqTsoVIEPHGfxK_tVzH728vEZ9fEh1KT3yQd3Qlw5rymmn/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB6500_6700%2F5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf I also found a Unisys Work Flow Language Manual at https://secure-web.cisco.com/1kA_uHiE-G1A7sGXBC5HoPSMp5fW4vfvjFj5j9xycmrZNaam7iTrPXi7J99dfmimzEXSQCvlEIWLVYTmqWIi_ppQXx7EhcWis6req-sTPOZAtLv0v9Qab-cy0PPqtJh0w9WRFiLO0GI-HF9EeHHQY9Hs7Z8wJEhMidWMTfzD-ZjsEhgtvoWzsw6cuX_vykPZkrmb50ARjm-rUHSkpvXaO4ApAY8TlxyULBeNyd08Y93MMaAQmgInbaZZOrQO1V8Vauv4GVEj7FXBJktaBNDTPmQGKUqpiO7HrDzWMNzq30bqN4qf9bxz31b0FwUGcS-lX8Cz-q2tI3WODN3fH66YKPlgTQhaGIh2YS_4lLn_4DoGWpvvT2FdziNB9hASYBgAUHKxC0B8Gq2X3fkJ4LshGOKnFi07gS6IkA53XatQ5fEfg0YfePYAasZr35Bt2-9xP/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516 The 1700 was a very odd machine that allowed for bit-addressable memory. While the physical memory was organized as 8-bit bytes, the higher level languages all had their own "interpreter", each of which allowed for allocation of storage on any bit boundary and with arbitrary bit length. The interpreters were the microcode to support a given language. There was one for Cobol, another for Fortran, and yet another for SDL. I understood SDL to be a subset of Algol, and it was the language that was used to write the MCP. Each interpreter was optimized for the language that it was designed for. Compiled instructions were of variable size, depending on the requirements of the program. A program that referenced few data items would need fewer bits in the instruction to reference those data items than one that referenced many data items. Pages were similarly variable in size, depending upon the requirements of the program that was running. Storage could be allocated in arbitrary increments. I did some experimentation and IIRC, I found that I could do the equivalent of a GETMAIN for 1 bit and it would be honored. Regardless of the size, a 48-bit header would be defined to describe it. If you want a peek into this rather odd system, here is a link the the 1700 System Reference manual: http://secure-web.cisco.com/1xDyW-vu-Dv_UI3m_YIQJyBu0rsCua4aPfkBHXhbwiEqORd0isbbjz6sSCQsVdHhy_byXdI4rVT8eMQuKWC6zUOyHFiBPgHbCaQV5cQaK1tUKYmbZGgUyC8iU0GJoabzUWpkjekGi_d2JeUMTeo5fKuAkD53eedbqjwOO0pptPzMhdOvO8PDyx9Lz3_rZcj_3K_nRedOxCGJIvvwDUJdwCuEgjFmJsM5TzBtdn-JUuqb2B8eGNqk5Jgn6AP8Vm5fBF-OAl1MVcSK-hD-Qb4pC8yCfWdUP1O063v3jnD1m_REvVUpw8XIoQdiZh5G0lqSbrv4QhaHN2FIS6BQ7tYiwFnzXPHJNHhsdA9xszkPt-qGD6qkgmFH5SZsBunPt153KglTNxPkHplpcUn0SDnEmo4DZQSeSKMP6djqSmI_Wbj9XjiuV8dFvpmJak0ssj7Zo/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB1700%2F1057155_B1700SysRefMan11-73.pdf And for a peek into the Master Control Program, the MCP refere
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
REXX as JCL replacement - Performance
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
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: Overrides (was: REXX as JCL replacement)
The syntax using stepname (not procstep name) is used because there is no nested procedure in that refer back. By that I mean, the reference is not to a DD within a proc invoked by the procedure. That is how I've always viewed it. I reread the JCL manual concerning backward references and it does not make that clear. But it does say *.stepname.ddname Asks the system to copy the data set name from DD statement, ddname, in an earlier step, stepname, in the same job. *.stepname.procstepname.ddname Asks the system to copy the data set name from a DD statement in a cataloged or in-stream procedure. Stepname is the name of this job step or an earlier job step that calls the procedure, procstepname is the name of the procedure step that contains the DD statement, and ddname is the name of the DD statement. >From which I imply that if you invoke a proc and want to refer to/override a >DD in that proc, you need to add procstep name to your reference, else its any >DD in the same job. JCL in the job that invokes the proc would need procstep >name. JCL within the proc would not. How many levels of nesting would that >remain true? I suspect just the one. I did not have much success having a >proc invoke a proc and try to override, in Job JCL or within the first proc, >DD statements in the nested proc. Cliff >The proc author probably wouldn't do in that manner. Look at excerpt below, >notice how LKED SYSLIN is referencing a dsn from a previous step? > >SYS1.PROCLIB(IBMZCPLG) - 01.01 Columns > ===> Scroll == >//* >//* PRE-LINK-EDIT STEP >//* >//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI) >//... >//SYSMOD DD DSN=&&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)), >// DCB=(RECFM=FB,LRECL=80,BLKSIZE=&SYSLBLK) >//* >//* LINK-EDIT STEP >//* >//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED)) >//... >//SYSLIN DD DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE) > Suppose the end user calls this with: //FOOBAR EXEC PROC=IBMZXPLG,... Doesn't the referback need to cite the job step, as in: //SYSLIN DD DSN=*.FOOBAR.PLKED.SYSMOD,DISP=(OLD,DELETE) ... but the author of the PROC can't know a priori the callers jobstep name. -- 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 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: Overrides (was: REXX as JCL replacement)
Paul, No, the PROC referback does NOT need to know the step name that invoked the PROC. It is the nearest prior procstepname that is referenced, so multiple compile PROC executions in the same job work just fine and refer to the correct dataset. AFAIK , that's been the case since PROC's were first introduced. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, July 11, 2018 3:48 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Overrides (was: REXX as JCL replacement) On Wed, 11 Jul 2018 19:30:16 +, Clifford McNeill wrote: >The proc author probably wouldn't do in that manner. Look at excerpt below, >notice how LKED SYSLIN is referencing a dsn from a previous step? > >SYS1.PROCLIB(IBMZCPLG) - 01.01 Columns > ===> Scroll == >//* >//* PRE-LINK-EDIT STEP >//* >//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI) >//... >//SYSMOD DD DSN=&&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)), >// DCB=(RECFM=FB,LRECL=80,BLKSIZE=&SYSLBLK) >//* >//* LINK-EDIT STEP >//* >//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED)) >//... >//SYSLIN DD DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE) > Suppose the end user calls this with: //FOOBAR EXEC PROC=IBMZXPLG,... Doesn't the referback need to cite the job step, as in: //SYSLIN DD DSN=*.FOOBAR.PLKED.SYSMOD,DISP=(OLD,DELETE) ... but the author of the PROC can't know a priori the callers jobstep name. -- 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: Overrides (was: REXX as JCL replacement)
On Wed, 11 Jul 2018 19:30:16 +, Clifford McNeill wrote: >The proc author probably wouldn't do in that manner. Look at excerpt below, >notice how LKED SYSLIN is referencing a dsn from a previous step? > >SYS1.PROCLIB(IBMZCPLG) - 01.01 Columns > ===> Scroll == >//* >//* PRE-LINK-EDIT STEP >//* >//PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI) >//... >//SYSMOD DD DSN=&&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)), >// DCB=(RECFM=FB,LRECL=80,BLKSIZE=&SYSLBLK) >//* >//* LINK-EDIT STEP >//* >//LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED)) >//... >//SYSLIN DD DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE) > Suppose the end user calls this with: //FOOBAR EXEC PROC=IBMZXPLG,... Doesn't the referback need to cite the job step, as in: //SYSLIN DD DSN=*.FOOBAR.PLKED.SYSMOD,DISP=(OLD,DELETE) ... but the author of the PROC can't know a priori the callers jobstep name. -- 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
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: Overrides (was: REXX as JCL replacement)
The proc author probably wouldn't do in that manner. Look at excerpt below, notice how LKED SYSLIN is referencing a dsn from a previous step? SYS1.PROCLIB(IBMZCPLG) - 01.01 Columns ===> Scroll == //* //* PRE-LINK-EDIT STEP //* //PLKEDEXEC PGM=EDCPRLK,COND=(8,LT,PLI) //STEPLIB DD DSN=&LIBPRFX..SCEERUN,DISP=SHR //SYSMSGS DD DSN=&LIBPRFX..SCEEMSGP(&PLANG),DISP=SHR //SYSLIB DD DUMMY //SYSMOD DD DSN=&&PLNK,DISP=(,PASS),UNIT=SYSALLDA,SPACE=(CYL,(1,1)), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=&SYSLBLK) //SYSIN DD DSN=*.PLI.SYSLIN,DISP=(OLD,DELETE) //SYSPRINT DD SYSOUT=* //SYSOUT DD SYSOUT=* //* //* LINK-EDIT STEP //* //LKED EXEC PGM=IEWL,PARM='XREF',COND=((8,LT,PLI),(8,LE,PLKED)) //SYSLIB DD DSN=&LIBPRFX..SCEELKED,DISP=SHR //SYSPRINT DD SYSOUT=* //SYSLIN DD DSN=*.PLKED.SYSMOD,DISP=(OLD,DELETE) Cliff McNeill From: IBM Mainframe Discussion List on behalf of Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Sent: Wednesday, July 11, 2018 2:10 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Overrides (was: REXX as JCL replacement) On Wed, 11 Jul 2018 10:35:08 -0700, Lizette Koehler wrote: >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. > I can't decide whether the author of the original RFE overlooked a requirement, perhaps assuming it was implicit, or IBM shirked the implementation. There ougnt to be an extended syntax, such as: //refdd DD sysxxx=*.jobstep.procstep.subprocstep.subsub ... .ddname BTW, what's the syntax by which a procstep can refer to a data set passed from an earlier procstep? Such as //MAKE PROC //C EXEC PGM=COMPILER,... //SYSPUNCH DDDISP=(,PASS), ... //L EXEC PGM=IEWL //SYSLINDDDISP=(OLD,PASS),DSN=*..C.SYSPUNCH It seems the author of the PROC needs to know, but can't know, the user's job step name to code as the . What am I missing? -- 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 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
Overrides (was: REXX as JCL replacement)
On Wed, 11 Jul 2018 10:35:08 -0700, Lizette Koehler wrote: >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. > I can't decide whether the author of the original RFE overlooked a requirement, perhaps assuming it was implicit, or IBM shirked the implementation. There ougnt to be an extended syntax, such as: //refdd DD sysxxx=*.jobstep.procstep.subprocstep.subsub ... .ddname BTW, what's the syntax by which a procstep can refer to a data set passed from an earlier procstep? Such as //MAKE PROC //C EXEC PGM=COMPILER,... //SYSPUNCH DDDISP=(,PASS), ... //L EXEC PGM=IEWL //SYSLINDDDISP=(OLD,PASS),DSN=*..C.SYSPUNCH It seems the author of the PROC needs to know, but can't know, the user's job step name to code as the . What am I missing? -- 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 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: IBM i as JCL replacement (was: Rexx as JCL replacement)
Jol has a comprehensive menu system too. Or it can be used with a PL/I type English like script. For example, Testjob: job; Print Sys1.Maclib(call); Clem Jantje. wrote: On Thu, 5 Jul 2018 15:08:01 -0500, Dana Mitchell wrote: Most everything is menu driven, Indeed it is, but hitting PF14 on that menu will show you the equivalent CL command with all the options you just filled in in the right place and with the correct syntax. Just cut&paste that into your CL source... or onto your command line for that matter. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
It's not at all unusual that when you have experience with multiple systems, you find features on each that you wish you had on the others, e.g., in TSO I miss XEDIT. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tom Marchant <000a2a8c2020-dmarc-requ...@listserv.ua.edu> Sent: Tuesday, July 10, 2018 11:58 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote: >How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and >successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS >JCL compare with VSE JCL? My memories of DOS360 JCL probably are >irrelevant. I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine that included essentially the entire Master Control Program (MCP) that ran on the bigger machines. I remember that Work Flow Language was considerably more powerful than JCL, but I don't remember any specifics. I had been working with JCL for a few years at the time. I have a vague recollection that there were a few things that you couldn't do in WFL that you could do in JCL. I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't find one, but I did find a 6700/7700 System Software Handbook that has a section on WFL. http://secure-web.cisco.com/1oaw3qgL4gjrPhX7F7mKUCWRYzVJCVNgBwvF4n69Tyh4AiTXZYpvdbYElQO_gQk39Aw8SKZL9EXHZxQC8j-HRQRZzE7dlu451IHUVHWRfCJtQ00yp5sP3tstyn70_nPF6jmBoZUYcr-9WsLkk3GQgxMPY6nEZ7ACnOrZvpA34fbcaetW1zYw5Vt6gheD3oNbMwgEhltw22YM32Lj5CJDN_QDcjNYf8R6VKTHVEi5KYN0IHZMPYXf6d4KjudGDEMh2PmecWl8oZZr2bOSkFLbzq-GZtvS0xmWFuKj3bPJz4GYa7E01_eypOi0haPjAeqCj29TtqDZUdB1Ll2lGlmMF1EAxNzR77A5iQsuvJgokfUnhlv2QGGJzURH-6JVXxr0GsisYrwaY1Mtu_nfA3YVqTsoVIEPHGfxK_tVzH728vEZ9fEh1KT3yQd3Qlw5rymmn/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB6500_6700%2F5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf I also found a Unisys Work Flow Language Manual at https://secure-web.cisco.com/1kA_uHiE-G1A7sGXBC5HoPSMp5fW4vfvjFj5j9xycmrZNaam7iTrPXi7J99dfmimzEXSQCvlEIWLVYTmqWIi_ppQXx7EhcWis6req-sTPOZAtLv0v9Qab-cy0PPqtJh0w9WRFiLO0GI-HF9EeHHQY9Hs7Z8wJEhMidWMTfzD-ZjsEhgtvoWzsw6cuX_vykPZkrmb50ARjm-rUHSkpvXaO4ApAY8TlxyULBeNyd08Y93MMaAQmgInbaZZOrQO1V8Vauv4GVEj7FXBJktaBNDTPmQGKUqpiO7HrDzWMNzq30bqN4qf9bxz31b0FwUGcS-lX8Cz-q2tI3WODN3fH66YKPlgTQhaGIh2YS_4lLn_4DoGWpvvT2FdziNB9hASYBgAUHKxC0B8Gq2X3fkJ4LshGOKnFi07gS6IkA53XatQ5fEfg0YfePYAasZr35Bt2-9xP/https%3A%2F%2Fpublic.support.unisys.com%2Faseries%2Fdocs%2FClearPath-MCP-18.0%2F86001047-516 The 1700 was a very odd machine that allowed for bit-addressable memory. While the physical memory was organized as 8-bit bytes, the higher level languages all had their own "interpreter", each of which allowed for allocation of storage on any bit boundary and with arbitrary bit length. The interpreters were the microcode to support a given language. There was one for Cobol, another for Fortran, and yet another for SDL. I understood SDL to be a subset of Algol, and it was the language that was used to write the MCP. Each interpreter was optimized for the language that it was designed for. Compiled instructions were of variable size, depending on the requirements of the program. A program that referenced few data items would need fewer bits in the instruction to reference those data items than one that referenced many data items. Pages were similarly variable in size, depending upon the requirements of the program that was running. Storage could be allocated in arbitrary increments. I did some experimentation and IIRC, I found that I could do the equivalent of a GETMAIN for 1 bit and it would be honored. Regardless of the size, a 48-bit header would be defined to describe it. If you want a peek into this rather odd system, here is a link the the 1700 System Reference manual: http://secure-web.cisco.com/1xDyW-vu-Dv_UI3m_YIQJyBu0rsCua4aPfkBHXhbwiEqORd0isbbjz6sSCQsVdHhy_byXdI4rVT8eMQuKWC6zUOyHFiBPgHbCaQV5cQaK1tUKYmbZGgUyC8iU0GJoabzUWpkjekGi_d2JeUMTeo5fKuAkD53eedbqjwOO0pptPzMhdOvO8PDyx9Lz3_rZcj_3K_nRedOxCGJIvvwDUJdwCuEgjFmJsM5TzBtdn-JUuqb2B8eGNqk5Jgn6AP8Vm5fBF-OAl1MVcSK-hD-Qb4pC8yCfWdUP1O063v3jnD1m_REvVUpw8XIoQdiZh5G0lqSbrv4QhaHN2FIS6BQ7tYiwFnzXPHJNHhsdA9xszkPt-qGD6qkgmFH5SZsBunPt153KglTNxPkHplpcUn0SDnEmo4DZQSeSKMP6djqSmI_Wbj9XjiuV8dFvpmJak0ssj7Zo/http%3A%2F%2Fbitsavers.trailing-edge.com%2Fpdf%2Fburroughs%2FB1700%2F1057155_B1700SysRefMan11-73.pdf And for a peek into the Master Control Program, the MCP reference manual can be found at: http://secure-web.cisco.com/1jgVvG2NXgtINUsPr--k-6ww_14W_1jm3G55RaQ9Ym4kvSHcWPejWSY2br-fpJb4mQwvkZDxl_Q8PLjg7zyfYtWLxa8gm8tYWdsb45rwa8Vf
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
On Tue, 10 Jul 2018 10:28:05 -0500, John McKown wrote: >I'm having a discussion on another, >gaming, forum where one person insists that I simply can't be doing what I >have been for about a month. Because I'm using a tool which "can't do >that". When my daughter was in high school she wrote a version of Space Invaders for the TI-84 graphing calculator. She learned a lot about optimizing code for performance with that project. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote: >How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and >successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS >JCL compare with VSE JCL? My memories of DOS360 JCL probably are >irrelevant. I worked on a Burroughs 1726 in the mid-1970's. It was an interesting machine that included essentially the entire Master Control Program (MCP) that ran on the bigger machines. I remember that Work Flow Language was considerably more powerful than JCL, but I don't remember any specifics. I had been working with JCL for a few years at the time. I have a vague recollection that there were a few things that you couldn't do in WFL that you could do in JCL. I looked around on Bitsavers for a 1700 manual that covered WFL. I couldn't find one, but I did find a 6700/7700 System Software Handbook that has a section on WFL. http://bitsavers.trailing-edge.com/pdf/burroughs/B6500_6700/5000722_B6700_B7700_System_Software_Handbook_Jul73.pdf I also found a Unisys Work Flow Language Manual at https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86001047-516 The 1700 was a very odd machine that allowed for bit-addressable memory. While the physical memory was organized as 8-bit bytes, the higher level languages all had their own "interpreter", each of which allowed for allocation of storage on any bit boundary and with arbitrary bit length. The interpreters were the microcode to support a given language. There was one for Cobol, another for Fortran, and yet another for SDL. I understood SDL to be a subset of Algol, and it was the language that was used to write the MCP. Each interpreter was optimized for the language that it was designed for. Compiled instructions were of variable size, depending on the requirements of the program. A program that referenced few data items would need fewer bits in the instruction to reference those data items than one that referenced many data items. Pages were similarly variable in size, depending upon the requirements of the program that was running. Storage could be allocated in arbitrary increments. I did some experimentation and IIRC, I found that I could do the equivalent of a GETMAIN for 1 bit and it would be honored. Regardless of the size, a 48-bit header would be defined to describe it. If you want a peek into this rather odd system, here is a link the the 1700 System Reference manual: http://bitsavers.trailing-edge.com/pdf/burroughs/B1700/1057155_B1700SysRefMan11-73.pdf And for a peek into the Master Control Program, the MCP reference manual can be found at: http://bitsavers.trailing-edge.com/pdf/burroughs/B1700/1088010B_1700MCPRefManAug75.pdf Perhaps another time I will tell the tale of what we bought the computer for and what happened with it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
On Tue, Jul 10, 2018 at 10:19 AM Seymour J Metz wrote: > It wouldn't help; lots of people don't know what they platform that they > are running on can do, much less other platforms. If I had $1 for every > time somebody told me that, e.g., ISPF, couldn't do that I'd been doing for > decades ... > Yeah, it applies to live in general. I'm having a discussion on another, gaming, forum where one person insists that I simply can't be doing what I have been for about a month. Because I'm using a tool which "can't do that". > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
Like I said, I was using cards when I last worked on VSE, so it's been a little while... ;) I'll be curious to hear whats changed too Dana On Tue, 10 Jul 2018 09:15:57 -0400, Tony Thigpen wrote: >I wish those of you not current on VSE would remember that we have had >just as many years to change things as z/OS has. Oh, wait, we have >longer. > >Later, when I have time, I will list some of those things. > >Tony Thigpen > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
It wouldn't help; lots of people don't know what they platform that they are running on can do, much less other platforms. If I had $1 for every time somebody told me that, e.g., ISPF, couldn't do that I'd been doing for decades ... -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Tony Thigpen Sent: Tuesday, July 10, 2018 9:15 AM To: IBM-MAIN@listserv.ua.edu Subject: Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement I wish those of you not current on VSE would remember that we have had just as many years to change things as z/OS has. Oh, wait, we have longer. DOS came out before what ever MVS was called back then. z/VSE has a lot of things in the JCL that z/OS has no equal to. I work both areas and there are many things in z/VSE that I miss in z/OS. There are also some things in z/OS that are not in z/VSE, but the last z/VSE to z/OS conversion I did, the client programmers hated the 'limitations' they found in z/OS and had to go do a lot of program changes due to these limits. Later, when I have time, I will list some of those things. Tony Thigpen ITschak Mugzach wrote on 07/10/2018 08:46 AM: > ... And I may add that if VSE JCL was so good, it wouldn't have so many > private extensions (and I've seem some of them). > > ITschak > > On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell wrote: > >> My memories of VSE JCL are dated, and quite possbily incorrect with >> current VSE, but I recall that I felt it was more complicated that MVS >> jcl. It had more types of statements (although fewer parms per type), >> JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To >> describe a disk file, potentially required at least 3 statements, ASSIGN, >> DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline >> files were not interchangeable as far as programs were concerned. >> >> An interesting 'feature' was that syntax checking was done at execution >> time, so when a JCL error was encountered, a console message was issued >> that required a reply, allowing you to retype the errant statement. So in >> the days of real card readers, if you needed to make a quick one time >> change to a job, you could just flip the card around backwards, causing >> 'Invalid Statement' console message prompt, allowing you to type in the >> statement you really wanted. >> >> Dana >> >> On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris >> wrote: >>> How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL >> probably are >>> irrelevant. >>> >>> Clark Morris >>> >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
[Default] On 10 Jul 2018 06:16:08 -0700, in bit.listserv.ibm-main t...@vse2pdf.com (Tony Thigpen) wrote: >I wish those of you not current on VSE would remember that we have had >just as many years to change things as z/OS has. Oh, wait, we have >longer. DOS came out before what ever MVS was called back then. > >z/VSE has a lot of things in the JCL that z/OS has no equal to. I work >both areas and there are many things in z/VSE that I miss in z/OS. There >are also some things in z/OS that are not in z/VSE, but the last z/VSE >to z/OS conversion I did, the client programmers hated the 'limitations' >they found in z/OS and had to go do a lot of program changes due to >these limits. > >Later, when I have time, I will list some of those things. Thes could and should lead to some RFEs being submitted. Clark Morris > >Tony Thigpen > >ITschak Mugzach wrote on 07/10/2018 08:46 AM: >> ... And I may add that if VSE JCL was so good, it wouldn't have so many >> private extensions (and I've seem some of them). >> >> ITschak >> >> On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell wrote: >> >>> My memories of VSE JCL are dated, and quite possbily incorrect with >>> current VSE, but I recall that I felt it was more complicated that MVS >>> jcl. It had more types of statements (although fewer parms per type), >>> JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To >>> describe a disk file, potentially required at least 3 statements, ASSIGN, >>> DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline >>> files were not interchangeable as far as programs were concerned. >>> >>> An interesting 'feature' was that syntax checking was done at execution >>> time, so when a JCL error was encountered, a console message was issued >>> that required a reply, allowing you to retype the errant statement. So in >>> the days of real card readers, if you needed to make a quick one time >>> change to a job, you could just flip the card around backwards, causing >>> 'Invalid Statement' console message prompt, allowing you to type in the >>> statement you really wanted. >>> >>> Dana >>> >>> On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris >>> wrote: How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL >>> probably are irrelevant. Clark Morris >>> >>> -- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
W dniu 2018-07-10 o 15:15, Tony Thigpen pisze: I wish those of you not current on VSE would remember that we have had just as many years to change things as z/OS has. Oh, wait, we have longer. DOS came out before what ever MVS was called back then. z/VSE has a lot of things in the JCL that z/OS has no equal to. I work both areas and there are many things in z/VSE that I miss in z/OS. There are also some things in z/OS that are not in z/VSE, but the last z/VSE to z/OS conversion I did, the client programmers hated the 'limitations' they found in z/OS and had to go do a lot of program changes due to these limits. Later, when I have time, I will list some of those things. Please, do. It will be interesting. Personally I don't know VSE, but heard about very few VSE advantages. -- Radoslaw Skorupka Lodz, Poland == -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.plsąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
On Tue, Jul 10, 2018 at 8:16 AM Tony Thigpen wrote: > I wish those of you not current on VSE would remember that we have had > just as many years to change things as z/OS has. Oh, wait, we have > longer. DOS came out before what ever MVS was called back then. > OS/360 -- either MFT or MVT. > > z/VSE has a lot of things in the JCL that z/OS has no equal to. I work > both areas and there are many things in z/VSE that I miss in z/OS. There > are also some things in z/OS that are not in z/VSE, but the last z/VSE > to z/OS conversion I did, the client programmers hated the 'limitations' > they found in z/OS and had to go do a lot of program changes due to > these limits. > > Later, when I have time, I will list some of those things. > I think that would be very interesting. I am eagerly awaiting. > > Tony Thigpen > -- There is no such thing as the Cloud. It is just somebody else’s computer. Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
I wish those of you not current on VSE would remember that we have had just as many years to change things as z/OS has. Oh, wait, we have longer. DOS came out before what ever MVS was called back then. z/VSE has a lot of things in the JCL that z/OS has no equal to. I work both areas and there are many things in z/VSE that I miss in z/OS. There are also some things in z/OS that are not in z/VSE, but the last z/VSE to z/OS conversion I did, the client programmers hated the 'limitations' they found in z/OS and had to go do a lot of program changes due to these limits. Later, when I have time, I will list some of those things. Tony Thigpen ITschak Mugzach wrote on 07/10/2018 08:46 AM: ... And I may add that if VSE JCL was so good, it wouldn't have so many private extensions (and I've seem some of them). ITschak On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell wrote: My memories of VSE JCL are dated, and quite possbily incorrect with current VSE, but I recall that I felt it was more complicated that MVS jcl. It had more types of statements (although fewer parms per type), JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To describe a disk file, potentially required at least 3 statements, ASSIGN, DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline files were not interchangeable as far as programs were concerned. An interesting 'feature' was that syntax checking was done at execution time, so when a JCL error was encountered, a console message was issued that required a reply, allowing you to retype the errant statement. So in the days of real card readers, if you needed to make a quick one time change to a job, you could just flip the card around backwards, causing 'Invalid Statement' console message prompt, allowing you to type in the statement you really wanted. Dana On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote: How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL probably are irrelevant. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
... And I may add that if VSE JCL was so good, it wouldn't have so many private extensions (and I've seem some of them). ITschak On Tue, Jul 10, 2018 at 2:37 PM Dana Mitchell wrote: > My memories of VSE JCL are dated, and quite possbily incorrect with > current VSE, but I recall that I felt it was more complicated that MVS > jcl. It had more types of statements (although fewer parms per type), > JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To > describe a disk file, potentially required at least 3 statements, ASSIGN, > DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline > files were not interchangeable as far as programs were concerned. > > An interesting 'feature' was that syntax checking was done at execution > time, so when a JCL error was encountered, a console message was issued > that required a reply, allowing you to retype the errant statement. So in > the days of real card readers, if you needed to make a quick one time > change to a job, you could just flip the card around backwards, causing > 'Invalid Statement' console message prompt, allowing you to type in the > statement you really wanted. > > Dana > > On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris > wrote: > > How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL > probably are > >irrelevant. > > > >Clark Morris > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
My memories of VSE JCL are dated, and quite possbily incorrect with current VSE, but I recall that I felt it was more complicated that MVS jcl. It had more types of statements (although fewer parms per type), JOB, * $$ JOB, UPSI, OPTION, LIBDEF, PAUSE, and EXEC statements. To describe a disk file, potentially required at least 3 statements, ASSIGN, DLBL, and EXTENT. Tape required ASSIGN and TLBL, tape, disk and inline files were not interchangeable as far as programs were concerned. An interesting 'feature' was that syntax checking was done at execution time, so when a JCL error was encountered, a console message was issued that required a reply, allowing you to retype the errant statement. So in the days of real card readers, if you needed to make a quick one time change to a job, you could just flip the card around backwards, causing 'Invalid Statement' console message prompt, allowing you to type in the statement you really wanted. Dana On Mon, 9 Jul 2018 16:41:40 -0300, Clark Morris wrote: > How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL probably > are >irrelevant. > >Clark Morris > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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. 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: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
WFL, Work Flow Language, actually. I had a very brief association with an employer's Burroughs 6500 long ago, and at the same time I actually wrote a term paper for an Operating Systems Survey course I was taking that compared WFL, MVS JCL and CDC6600 Control Language. WFL was the clear winner by a huge margin. Thanks for the lovely memory. I really enjoyed researching and writing that paper. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Clark Morris Sent: Monday, July 9, 2018 3:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement [Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main edja...@phoenixsoftware.com (Ed Jaffe) wrote: >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..." How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL probably are irrelevant. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to 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
Burroughs WFM vs. z/OS JCl and VSE JCL wasRe: REXX as JCL replacement
[Default] On 9 Jul 2018 11:14:20 -0700, in bit.listserv.ibm-main edja...@phoenixsoftware.com (Ed Jaffe) wrote: >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..." How would the WFM (Work Flow Manager IIRC) for the Burroughs B500 and successor compare with IBM z/OS JCL and with VSE JCL. How does z/OS JCL compare with VSE JCL? My memories of DOS360 JCL probably are irrelevant. Clark Morris > >https://youtu.be/8c0_Lzb1CJw?t=4735 -- 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: IBM i as JCL replacement (was: Rexx as JCL replacement)
On Thu, 5 Jul 2018 15:08:01 -0500, Dana Mitchell wrote: >Most everything is menu driven, Indeed it is, but hitting PF14 on that menu will show you the equivalent CL command with all the options you just filled in in the right place and with the correct syntax. Just cut&paste that into your CL source... or onto your command line for that matter. Cheers, Jantje. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
