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 <[email protected]> On Behalf Of > Hobart Spitz > Sent: Wednesday, July 11, 2018 10:30 AM > To: [email protected] > 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 <[email protected]> > 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 > > [email protected] > > > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:[email protected]] > > On Behalf Of Hobart Spitz > > Sent: Wednesday, July 11, 2018 9:42 AM > > To: [email protected] > > 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 < > > 0000000433f07816-dmarc- [email protected]> 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 [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
