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 <[email protected]> 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 <[email protected]> on behalf > of Hobart Spitz <[email protected]> > Sent: Wednesday, July 11, 2018 1:30 PM > 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://secure-web.cisco.com/1vPv31WBXBT1zFq5Jok_ > TQrDIW17DDLt3jbvRME3ZinOiLdfN7IJ9HM9i0r-y969-qSZy8zN__ > 1EC982Nn1N1MNPVzPnnotq686mQo7NcBidOmguumNuGzCKnQj3_ > wjdNOsymf5WluMaEcQxFcYWWObgQahYyErJAZX8OuB2tGU50qKbGDIxtAMT7 > 4iWjCC15wrGFlMzwvpNLTkVt9VfMa1dZ1zG-jItf3aT_1Ki40dTVC- > 8RTypOjtuDtNwPE1cGDXpqiNfCZ2nGwVYeiTfw-sK5KpbqpXAw28GrkRBzxse01OsmrZY > QczcQzNCqanz3xSqYZ1dEqoKnSSYfUDqGLH5XWvpHiHt2AskNPZCZ- > 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/1DkJEaI3yU5IZP37yYVRY2GReQj7wR > 1FZPTlPwK3qOcYqAfweqMv0_zybvyhmIgS0XluyeavRY5xC4c_ > Ccn3IlXPYzsQD6UV9ukzp6z1pZwfvfDlwVxbfUJ_DUmp1LasHuRZmMyQ4ry-_YSz_ > 1TXlfs4P1xFb9jSU8KFnBcZrpkrXnIQgR_VMdQBvG_YmofM8LoTiRzDVVBIiBoObEbUg1kwo > pu5GMy1qJ4JZUcZY9H_m6Luth7RBt8TIeBJuXOWR3UcyCRlMl > nvkxmKPMl2GMU0NaGyoOnRxkBBivWx9Fvk4vxkmZA3hI9Dy7O_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- > > [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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
