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 <IBM-MAIN@listserv.ua.edu> on behalf of Hobart Spitz <orexx...@gmail.com> 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 <jesse1.robin...@sce.com> 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 > > http://secure-web.cisco.com/1vPv31WBXBT1zFq5Jok_TQrDIW17DDLt3jbvRME3ZinOiLdfN7IJ9HM9i0r-y969-qSZy8zN__1EC982Nn1N1MNPVzPnnotq686mQo7NcBidOmguumNuGzCKnQj3_wjdNOsymf5WluMaEcQxFcYWWObgQahYyErJAZX8OuB2tGU50qKbGDIxtAMT74iWjCC15wrGFlMzwvpNLTkVt9VfMa1dZ1zG-jItf3aT_1Ki40dTVC-8RTypOjtuDtNwPE1cGDXpqiNfCZ2nGwVYeiTfw-sK5KpbqpXAw28GrkRBzxse01OsmrZYQczcQzNCqanz3xSqYZ1dEqoKnSSYfUDqGLH5XWvpHiHt2AskNPZCZ-jVGhgYnuAQFJkSQu-REVCUi/http%3A%2F%2Fvm.marist.edu%2F%7Epipeline%2F > > The author's edition, the primary source of PIPElines information, can be > found at. > > http://secure-web.cisco.com/1DkJEaI3yU5IZP37yYVRY2GReQj7wR1FZPTlPwK3qOcYqAfweqMv0_zybvyhmIgS0XluyeavRY5xC4c_Ccn3IlXPYzsQD6UV9ukzp6z1pZwfvfDlwVxbfUJ_DUmp1LasHuRZmMyQ4ry-_YSz_1TXlfs4P1xFb9jSU8KFnBcZrpkrXnIQgR_VMdQBvG_YmofM8LoTiRzDVVBIiBoObEbUg1kwopu5GMy1qJ4JZUcZY9H_m6Luth7RBt8TIeBJuXOWR3UcyCRlMlnvkxmKPMl2GMU0NaGyoOnRxkBBivWx9Fvk4vxkmZA3hI9Dy7O_CN0V9rl1ssWoJvA_8CcKN9r78DnLq0lwrcSPjYJZ4kP0VNqs5J6CXjzLe5Mj6QSF4gGtT/http%3A%2F%2Fwww-01.ibm.com%2Fsupport%2Fdocview.wss%3Fuid%3Dpub1sl26001805 > > 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 > ---------------------------------------------------------------------- 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
