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 < 0000000433f07816-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
