Re: [IBM External] Re: [IBM External] Re: IPL's POR's frequency
"a fully configured parallel sysplex" - in the sense you meant it - is something I see less often than I'd like. :-( As a Performance guy, often the conversations I have with customers - based on their data - have a big dollop of Resilience in them. There are those that have embraced "a fully configured parallel sysplex", those that hope to be able to swing work across, and those that don't even have that. Cheers, Martin Sent from my iPad > On 24 Sep 2021, at 05:43, Skip Robinson wrote: > > If you have a fully configured parallel sysplex, disruption to clients > should be minimal. On balance, less disruption than a system crash caused > by downlevel maintenance. > >> On Thu, Sep 23, 2021 at 9:33 PM Brian Westerman < >> brian_wester...@syzygyinc.com> wrote: >> >> One of the things that you "lose" when only IPLing once or twice per year >> is the ability to install maintenance on a more frequent basis, at least >> anything but individual fixes. To try to install an RSU upgrade without an >> IPL will be very foolish. >> >> As we previously stated by me and others, your maintenance schedule would >> have impact on your IPL plans. :) >> >> If you have a client that wants to stay at quarterly RSU levels, then you >> would be most likely be going to IPL quarterly >> >> Brian >> > -- > > Skip Robinson > 323-715-0595 > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAINUnless > stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)
Mike wrote: >Could something be developed similar to a SORTOUT exit that implements this switch? BatchPipes fittings are like sort exits on steroids: They can be applied to almost any DD, can use most Pipes filters, do not require compiled code, and they are not restricted to a single program. I plan to say more later. In a nutshell: I think BatchPipes, including the Pipe command, should be in the z/OS base. It would be the biggest enhancement to JCL ever, and would be of much more interest to production oriented management who care about stability. OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. IBM has been looking for an HLL for program products; REXX is that language. On Mon, Sep 20, 2021 at 7:11 PM Mike Schwab wrote: > So, in a sense, instead of pipes, the programs could be modified so > that instead of outputting a record, call the next program passing the > record as input. > > Could something be developed similar to a SORTOUT exit that implements > this switch? > > On Mon, Sep 20, 2021 at 4:27 PM Hobart Spitz wrote: > > > > Phil; > > > > This is a great comment. I hadn't given that much thought to the > question. > > > > Not to split hairs, but I didn't say MIPS, I said hardware. > > > > If I had to guess, MIPS usage might actually increase slightly, because > the > > Pipes dispatcher has to switch between stages twice for every record that > > is passed. Access method overheard would drop. Buffered access methods, > > in most cases, only have to increment the pointer into the block buffer, > > check for end-of-buffer and return to the caller. I don't know for sure > > which is larger. Maybe someone more knowledgeable than I can shed some > > light. > > > > I would say the real savings would be in elapsed run time and working set > > size. Run time, due to eliminating something like 80-95% of I/O > operations > > for intra-JOB datasets. Working set reduction would save on real memory. > > (See below.) Run time is probably more of a concern to customers, > > especially those with tight batch windows. That said, working set size > > reduction would mean that processors would likely spend more, if not all, > > time pegged at 100% busy, because so many more address spaces (TSO and > JOB) > > would be in a swapped-in and ready state than before. Depending on what > > metrics the capacity planners are looking at, CPU sales might actually > > increase. As I think about it more, if thru-put increases, new data > could > > be generated more quickly and other times of hardware could be more in > > demand during peak load times. I just don't know enough to say for sure. > > > > Phil and others know what follows. > > > > For those who don't know, in the typical case, a record passes through > all > > possible stages before the next record begins the same trip. Each record > > stays in the working page set, at least partially, during the entire > time. > > Parts that are referenced have a good chance of staying cache resident > > between stages. > > > > Think of it this way: You can visualize UNIX piping as a series of > > hourglasses open at both ends and connected in a tower. Each grain of > sand > > must stop at every "stage" and wait its turn to go through the narrow > > opening at the waist of each hourglass. In Pipes, most stages have no > > delay and it's like a single tall hourglass tube with only one narrow > > point. My best guess is that Pipes, in this analogy, would have only > > 5%-15% of the narrow openings as an equivalent UNIX piping command, > meaning > > that the data (sand) would flow 85-95% faster in the Pipes "hourglass". > > > > > > OREXXMan > > Would you rather pass data in move mode (*nix piping) or locate mode > > (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands > > with more than a dozen filters, while Pipelines specifications are > commonly > > over 100s of stages, and 1000s of stages are not uncommon. > > IBM has been looking for an HLL for program products; REXX is that > language. > > > > > > On Mon, Sep 20, 2021 at 12:48 PM Phil Smith III wrote: > > > > > Hobart Spitz wrote, in part: > > > > > > >The case *for *Pipes in the z/OS base.: > > > > > > > 2. Hardware usage would drop for customers. > > > > > > > > > > > > From IBM's perspective, that might not be a positive argument. It > should > > > be-they're hopefully not fooling themselves that they have a lock on > > > enterprise computing any more, so anything that makes life more > palatable > > > for the remaining faithful at low cost to IBM should be A Good > Thing-but I > > > can easily imagine someone saying, "We estimate this will reduce MIPS > > > purchases by x%, that's bad, don't do it". > > > > > > > > > > > > Just sayin'. > > > >
Re: zPDT Learner's Edition
Someone on one of the mainframe groups.io lists posted this link to a LinkedIn article on this offering by Ray Mullins: https://www.linkedin.com/posts/raymullins_ibmz-activity-684653939335168-Ah68 Interesting reading. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Thursday, September 23, 2021 5:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zPDT Learner's Edition Not aimed at you Lennie :-) , not pre-announcing anything :-), having no insight to bring, but at that price I'd like to think of that also as Retiree Edition. No smiley because I'm serious that I would consider it. It's about the price of an Apple Developer annual subscription - which I would also contemplate. Cheers, Martin Martin Packer From: "Lennie Bradshaw" <032fff1be9b4-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 23/09/2021 09:54 Subject:[EXTERNAL] zPDT Learner's Edition Sent by:"IBM Mainframe Discussion List" Has anyone else any information on the zD&T Learner's Edition that was recently shown on the IBM zZ&T pages? https://urldefense.com/v3/__https://www.ibm.com/products/z-development-test-environment/pricing__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!e6s4GrbspsWRsmf9f3O797RROjrxlWFUmkU18Bh0j2YmHcaRQLh97sEmtJCCkSj2Wug8dQ$ It appears that IBM has removed some references to it now, although the FAQs on that page (need to scroll down) still show a question with a price of $120 per annum once a person is "Qualified". Any comments from IBM would be useful. -- 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: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)
Phil, thanks again for the helpful feedback and the great food for thought. Your point is well taken. I'll try to break it down as best I can: MIPS or CPU usage, main memory or working set, and input/output operations. (I'd be happy if someone else has better information.) MIPS is dependent on at least three things: Arithmetic Logical Unit (ALU) usage, instruction pipeline activity, and cache misses. With Pipes, ALU and instruction pipeline usage would be more intense, while cache misses would be less so. Many characters, ones that the Pipes stages never even look at, won't even enter the cache and ALU. Some data can be processed through thousands of stages and only be cache missed a few times, because stages are typically dispatched one after the other to process the same record. Compared to UNIX piping, where every character of a text file must go through every stage, even if it is going to be ignored, Pipes is much faster. As Melinda Varian says (approximately): This is an advantage of file structure aware operating systems. I could include Pipes as systems software. Main memory (i.e., non-cache) and working set affect how fast instructions can be executed. As with characters, records can enter and leave the working set just a few times, and still be processed by thousands of stages. So the working sets of Pipes will mostly tend to be much lower. Stages like TAKE and DROP can do their work without ever referencing a single byte of the records being processed. (With UNIX head and tail, every character must be inspected by the CPU.) Finally, there is I/O, which is where Pipes and even UNIX piping really shine. The fastest input and output operations are the ones that never take place. Records moved from program to program in memory skip I/O. I/O generally involves some kind of mechanical movement, and which is far slower than the CPU, caches or real memory. Taken together, a set of Pipes stages, whether in a TSO PIPE command or in a BatchPipes Fitting on a DD, \will have a smaller average working set and spend less time in the system than alternatives. If we estimate costs as WS*ER (working set size times elapsed residency), even a conservative 50% reduction in each would mean about a 75% reduction in hardware usage. (WS*0.5)*(ER*0.5) = WS*ER*0.25. If you have been paying attention, I have purposely glossed over some details. Unreferenced characters may be cache loaded because they reside on the same cache line as referenced characters. Also, record length and blocking factor, among other things, affect how fast data can reach main memory, the caches, and then the ALU. On the average, I don't think these two details change the relative effects of Pipes processing versus conventional processing.. I suspect that UNIX piping was the inspiration for Pipes (A.K.A. CMS/TSO Pipelines and BatchPipesWorks) both in suggesting in-memory "I/O" as well as improvements to the concept. I hope this helps. OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. IBM has been looking for an HLL for program products; REXX is that language. On Mon, Sep 20, 2021 at 8:10 PM Phil Smith III wrote: > Hobart Spitz wrote, in part: > > >This is a great comment. I hadn't given that much thought to the > question. > > >Not to split hairs, but I didn't say MIPS, I said hardware. > > >If I had to guess, MIPS usage might actually increase slightly, because > the > >Pipes dispatcher has to switch between stages twice for every record that > >is passed. > > > > Sure, just sayin' you'd want to be very clear about what you do mean. > > > > I'm not quite sure what you mean by "more MIPS but less hardware", though? > > > -- > 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: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)
On Fri, 24 Sep 2021 08:01:27 -0500, Hobart Spitz wrote: >Mike wrote: >>Could something be developed similar to a SORTOUT exit that implements >this switch? >BatchPipes fittings are like sort exits on steroids: They can be applied >to almost any DD, ... > SORTWKnn? A problem posed earlier was to estimate the size of the sort. I''m imagining a FANOUT to two pipelines: o One | COUNT RECORDS to measure the size o One | ELASTIC | DD:SORTIN A critique of this idea is left as an exercise for the student. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zPDT Learner's Edition
Sounds nice. I'll need to remove the years of encrustation and rust from my LinkedIn account. On Fri, Sep 24, 2021 at 8:59 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: > Someone on one of the mainframe groups.io lists posted this link to a > LinkedIn article on this offering by Ray Mullins: > > > https://www.linkedin.com/posts/raymullins_ibmz-activity-684653939335168-Ah68 > > Interesting reading. > > Peter > > -Original Message- > From: IBM Mainframe Discussion List On Behalf > Of Martin Packer > Sent: Thursday, September 23, 2021 5:00 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: zPDT Learner's Edition > > Not aimed at you Lennie :-) , not pre-announcing anything :-), having no > insight to bring, but at that price I'd like to think of that also as > Retiree Edition. No smiley because I'm serious that I would consider it. > It's about the price of an Apple Developer annual subscription - which I > would also contemplate. > > Cheers, Martin > > Martin Packer > > > From: "Lennie Bradshaw" <032fff1be9b4-dmarc-requ...@listserv.ua.edu> > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 23/09/2021 09:54 > Subject:[EXTERNAL] zPDT Learner's Edition > Sent by:"IBM Mainframe Discussion List" > > Has anyone else any information on the zD&T Learner's Edition that was > recently shown on the IBM zZ&T pages? > > https://urldefense.com/v3/__https://www.ibm.com/products/z-development-test-environment/pricing__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!e6s4GrbspsWRsmf9f3O797RROjrxlWFUmkU18Bh0j2YmHcaRQLh97sEmtJCCkSj2Wug8dQ$ > > > It appears that IBM has removed some references to it now, although the > FAQs on that page (need to scroll down) still show a question with a price > of > $120 per annum once a person is "Qualified". > > Any comments from IBM would be useful. > > -- > > 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
Re: The Business Case for Pipes in the z/OS Base (was: Re: REXX - Interpret or Value - Which is better?)
Martin wote: >I'm not familiar with FANOUT but if it writes a record to, say, two destinations, it's got to copy one of them. Actually not. I know it sounds like magic, but there is still only one copy. I'll give you my best rendition of what I think is happening. Don't worry if you don't get the whole picture. I had to work with Pipes for many years before I understood this. Pipes manages the storage for records. When a new record is created (or modified) Pipes allocates the space for it. That pointer is what a stage gets when it asks for an input record. When an input record is no longer needed by a stage, Pipes is informed. This is referred to as "consuming" the record. In fact, the record is not "consumed", as in grinding with teeth and digesting, rather it is how a stage tells Pipes that it's done with the record. Changes are made to new storage at a new record address. Changing a record means getting new storage and building a new record, with the changes. The input record is not changed, and it can be inspected by other streams via FANOUT or any multiwrite stage. When the storage area of a record is no longer used by any stage, i.e., no stage has a pointer to it, that storage can be reclaimed by Pipes. I don't know the exact mechanism, but that's it at a high level. No matter how many streams and stages use a record, there is only one copy. DUP, for example, could just write the record over and over using the same pointer. (I don't know that for a fact, but John Hartmann is a lot smarter than I.) The majority of Pipes building stages do not modify their input records. (With REXX user written stages, there always is a new copy on output, even if no changes were made to the data.) OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. IBM has been looking for an HLL for program products; REXX is that language. On Thu, Sep 23, 2021 at 9:44 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Thu, 23 Sep 2021 09:30:43 +0100, Martin Packer wrote: > > >I'm not familiar with FANOUT but if it writes a record to, say, two > >destinations, it's got to copy one of them. > > > It could be deferred; Copy-on-Write, optimizing for what Hobart earlier > calledd the "typical case" of stages that don't modify the data. > But incurring the complexity of a responsibility count. > > > >From: "Hobart Spitz" > >Date: 23/09/2021 04:18 > > > >> I'm guessing the atypical case is a stage such as FANOUT which > >> necessarily copies the data. > > > >Not sure what you mean by atypical. > > > I apologize; I trimmed your earlier mention of "typical case". > > -- 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: zPDT Learner's Edition
Ha ha - and worse for me. Getting a LinkedIn account will be more upsetting to me than the $120 :) Hope I'm allowed to get one of the dongles, even just to see how it all works. Like Ray, for years I've been advocating something free or nearly free with every IBM manager I happen to see. No effect so far. If this works it could be a big change for future education. On 9/24/2021 7:22 AM, John McKown wrote: Sounds nice. I'll need to remove the years of encrustation and rust from my LinkedIn account. On Fri, Sep 24, 2021 at 8:59 AM Farley, Peter x23353 < 031df298a9da-dmarc-requ...@listserv.ua.edu> wrote: Someone on one of the mainframe groups.io lists posted this link to a LinkedIn article on this offering by Ray Mullins: https://www.linkedin.com/posts/raymullins_ibmz-activity-684653939335168-Ah68 Interesting reading. Peter -Original Message- From: IBM Mainframe Discussion List On Behalf Of Martin Packer Sent: Thursday, September 23, 2021 5:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: zPDT Learner's Edition Not aimed at you Lennie :-) , not pre-announcing anything :-), having no insight to bring, but at that price I'd like to think of that also as Retiree Edition. No smiley because I'm serious that I would consider it. It's about the price of an Apple Developer annual subscription - which I would also contemplate. Cheers, Martin Martin Packer From: "Lennie Bradshaw" <032fff1be9b4-dmarc-requ...@listserv.ua.edu> To: IBM-MAIN@LISTSERV.UA.EDU Date: 23/09/2021 09:54 Subject:[EXTERNAL] zPDT Learner's Edition Sent by:"IBM Mainframe Discussion List" Has anyone else any information on the zD&T Learner's Edition that was recently shown on the IBM zZ&T pages? https://urldefense.com/v3/__https://www.ibm.com/products/z-development-test-environment/pricing__;!!Ebr-cpPeAnfNniQ8HSAI-g_K5b7VKg!e6s4GrbspsWRsmf9f3O797RROjrxlWFUmkU18Bh0j2YmHcaRQLh97sEmtJCCkSj2Wug8dQ$ It appears that IBM has removed some references to it now, although the FAQs on that page (need to scroll down) still show a question with a price of $120 per annum once a person is "Qualified". Any comments from IBM would be useful. -- 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 . -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zPDT Learner's Edition
On 9/24/21 9:41 AM, Tom Brennan wrote: Like Ray, for years I've been advocating something free or nearly free with every IBM manager I happen to see. No effect so far. If this works it could be a big change for future education. I feel like $120 / year is well within the reach of any student or hobbyist that wants to learn. It's *SIGNIFICANTLY* more approachable than the $5k entry point for other options for professionals from IBM. It seems as if the announcement on IBM's site may have been slightly premature (O(weeks)) as it has purportedly been withdrawn and someone else in the community has said that it should be available in mid October. I'm very much looking forward to seeing how this rolls out. I love the idea of having an IBM supported way to run contemporary z/OS along side my well seasoned P/390-E. :-) -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: EXTERNAL EMAIL: Re: zPDT Learner's Edition
Agreed - $120 is something affordable by most, and I'm really excited to see this coming out Jerry Whitteridge jerry.whitteri...@albertsons.com Manager Mainframe Systems & HP Non-Stop Albertsons Companies -Original Message- From: IBM Mainframe Discussion List On Behalf Of Grant Taylor Sent: Friday, September 24, 2021 8:58 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: EXTERNAL EMAIL: Re: zPDT Learner's Edition On 9/24/21 9:41 AM, Tom Brennan wrote: > Like Ray, for years I've been advocating something free or nearly free > with every IBM manager I happen to see. No effect so far. If this > works it could be a big change for future education. I feel like $120 / year is well within the reach of any student or hobbyist that wants to learn. It's *SIGNIFICANTLY* more approachable than the $5k entry point for other options for professionals from IBM. It seems as if the announcement on IBM's site may have been slightly premature (O(weeks)) as it has purportedly been withdrawn and someone else in the community has said that it should be available in mid October. I'm very much looking forward to seeing how this rolls out. I love the idea of having an IBM supported way to run contemporary z/OS along side my well seasoned P/390-E. :-) -- Grant. . . . unix || die -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Warning: All e-mail sent to this address will be received by the corporate e-mail system, and is subject to archival and review by someone other than the recipient. This e-mail may contain proprietary information and is intended only for the use of the intended recipient(s). If the reader of this message is not the intended recipient(s), you are notified that you have received this message in error and that any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
The Business Case for **BatchPipes** in the z/OS Base
As a developer, I love REXX and I love Pipes. Together, they are programmer heaven. Whenever I write something new, whether in z/OS or z/VM, I write a REXX EXEC. Under z/OS, I SPAWN the EXEC when I want to run it in batch. I have used BatchPipes only briefly, but I know Pipes fairly well. Pipes are the language of BatchPipes Fittings, which is essentially an enhancement to allow Pipes stages to run on most DDs. I do not like BatchPipes. They require opsys or sysprog assistance and are too much trouble to use. They support inter-JOB piping which makes the real valuable part (intra-step piping) complicated and hard to use That said, for the rest of this note, I will PRETEND to be someone with production support responsibilities. If some of these things have no connection to anything that any site would actually do, I apologize. I'm just a color-blind painter trying to paint a picture that will give you the idea. In an imaginary future, some production control person may write: I love BatchPipes! Since we started using it, our batch production run time has steadily dropped and is now just 20% of what it was. We were able to shorten the run-times of the longest running JOBs to a small fraction. The DBAs love that they can start their maintenance and backups earlier and with plenty of time to spare. Much of the time, instead of writing a new step or a new JOB, we can accomplish the same thing with no new code, other than a JCL change. We just put a pipe fitting on a DD. It can be a temporary override or a permanent change. Did we get a dataset with the wrong DCB? Add a pipe fitting to the DD. No need to copy over the dataset. Did we get raw, unconverted ASCII data in transmission? No problem. Pipe fitting! Did the developer forget to add record counts to the summary report ? Easy-peasy! Add pipe fitting to the DDs. It doesn't matter if it's too big for ISPF EDIT. The size of the files that we can fix are not limited to available memory. There seems no noticeable increase in resource usage or run time when we address a production problem this way.. One of our developers had this crazy idea to convert all our JCL and COBOL to REXX and Pipes. That's not happening. On the other hand, I'm going to propose that special approval be required to develop and put into production any new JCL streams or COBOL programs. That guy had taken a 600+ line COBOL program and rewrote it in a Pipe command of a dozen lines. Granted it had been over-maintained and had lot's of unreachable, fossil code. That's the problem with JCL and COBOL. There are not enough real comments and it's all too verbose to understand the big picture. BatchPipes Fittings are the greatest enhancement to JCL since the first days of OS/360 JCL in the 1950s. I'm so glad IBM put BatchPipes and the REXX compiler in the z/OS base. It's made my job so much easier. No panic fixes or work-arounds. No complicated control cards. No OPENs, READ-WRITE loops, EOF logic or CLOSEs. Just simple, reliable changes, done right the first time. We haven't needed to use the REXX Compiler, but we're glad to have it in case we need a Plan B. End of "production control person" comments. Granted, it 's not the most entertaining fiction ever written, not by a long shot. I hope it got the idea across. OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. IBM has been looking for an HLL for program products; REXX is that language. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zPDT Learner's Edition
Glad you mentioned "contemporary z/OS". Even if the thing runs slower than an A01, modern software makes it far better for education than the Hercules TK4 setup or even the elephant Ray mentioned. P.S. If I run your email sig through Rexx it comes up with UNIXDIE which is probably not what you wanted :) On 9/24/2021 8:57 AM, Grant Taylor wrote: On 9/24/21 9:41 AM, Tom Brennan wrote: Like Ray, for years I've been advocating something free or nearly free with every IBM manager I happen to see. No effect so far. If this works it could be a big change for future education. I feel like $120 / year is well within the reach of any student or hobbyist that wants to learn. It's *SIGNIFICANTLY* more approachable than the $5k entry point for other options for professionals from IBM. It seems as if the announcement on IBM's site may have been slightly premature (O(weeks)) as it has purportedly been withdrawn and someone else in the community has said that it should be available in mid October. I'm very much looking forward to seeing how this rolls out. I love the idea of having an IBM supported way to run contemporary z/OS along side my well seasoned P/390-E. :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zPDT Learner's Edition
On 9/24/2021 8:57 AM, Grant Taylor wrote: It seems as if the announcement on IBM's site may have been slightly premature (O(weeks)) as it has purportedly been withdrawn and someone else in the community has said that it should be available in mid October. ISTR the "z/OS Hobby License" SHARE requirement being submitted in the mid-to-late 2000s (by Lionel Dyck?) back when I was MVS Core Technologies Project Manager. It's not the oldest SHARE requirement by any means, but certainly a long-standing one with an indefensible rationale, that has withstood the test of time. The SHARE MVS Program have patiently watched IBM's "ice" on this topic melt slowly with each passing year and with each passing change in z/OS Development leadership. It appears we may be on the precipice of this dream finally becoming reality. Kudos to Meredith Stowell and her team at IBM for all the hard work they have put into this effort... -- 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: zPDT Learner's Edition
A silver lining to global warming? On Fri, Sep 24, 2021 at 9:56 AM Ed Jaffe wrote: > On 9/24/2021 8:57 AM, Grant Taylor wrote: > > It seems as if the announcement on IBM's site may have been slightly > > premature (O(weeks)) as it has purportedly been withdrawn and someone > > else in the community has said that it should be available in mid > > October. > > ISTR the "z/OS Hobby License" SHARE requirement being submitted in the > mid-to-late 2000s (by Lionel Dyck?) back when I was MVS Core > Technologies Project Manager. It's not the oldest SHARE requirement by > any means, but certainly a long-standing one with an indefensible > rationale, that has withstood the test of time. > > The SHARE MVS Program have patiently watched IBM's "ice" on this topic > melt slowly with each passing year and with each passing change in z/OS > Development leadership. It appears we may be on the precipice of this > dream finally becoming reality. > > Kudos to Meredith Stowell and her team at IBM for all the hard work they > have put into this effort... > > -- > Phoenix Software International > Edward E. Jaffe > 831 Parkview Drive North > El Segundo, CA 90245 > https://www.phoenixsoftware.com/ > > -- Skip Robinson 323-715-0595 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
