Re: zPDT Learner's Edition
On 9/27/2021 1:39 PM, Phil Smith III wrote: Ed Jaffe wrote: 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. "indefensible"? "unimpeachable"? What did you mean? I meant to say there was _no defense_ that could be used by IBM against the rationale presented in the requirement. -- 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: PL/I vs. JCL
- Original Message - From: "Charles Mills" To: Sent: Tuesday, September 28, 2021 11:19 AM column 1 is reserved for carriage control. That seems to conflate source code with SYSPRINT. It does seem to, but in fact PL/I supports source listing formatting using ANSI carriage control. "The MARGINS option specifies which part of each compiler input record contains PL/I statements, and the position of the ANS control character that formats the listing, ..." -- PL/I P/G At some stage, the preprocessor commands %PAGE and %SKIP were introduced to improve source listings. Maybe they were always there, but I have a vague recollection that at some stage it was not necessary to have the preprocessir activated to make them work. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I vs. JCL
From: "Joe Monk" To: Sent: Tuesday, September 28, 2021 8:36 AM PL/I is free format. The default is 2 - 72, IBM's catalogue procedure was set up for columns 2 to 72. Sites could change that -- as ours did -- to read columns 1 to 80. but there is a compiler option to change that (SORMGIN). Joe --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I vs. JCL
- Original Message - From: "Mike Schwab" To: Sent: Tuesday, September 28, 2021 8:12 AM PL/I uses column one for a carriage control while JCL requires a / in column one, so this was never a problem PL/I does not use card column 1 for carriage control. That was an option that a programmer could use, but IIRC, that option was not available with the initial release. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I vs. JCL
- Original Message - From: "Phil Smith III" To: Sent: Tuesday, September 28, 2021 8:08 AM A friend writes: In a conversation elsewhere I mentioned the oops between JCL using /* as end of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had to start in column 2 to prevent a comment from being interpreted as JCL. PL/I source program could start between card columns 1 and 80, as we did on our site. IBM had set up some catalogue procedures to use only card columns 2 to 72. We changed that. All the programmer needed to do was to avoid starting a comment in card column 1. As for the PL/I SSP, we converted the card images from 48-character set to the 64-character set. At the same time, we removed the card numbers in card columns 73 to 80, and inserted card numbers within a comment starting in card column 73 and finishing at card column 80. Oopsie. Does anyone remember which came first? There was some rumor that I no longer remember that one group didn't like the other group so some of this done on purpose. I've never heard this, which proves nothing much, but leads me to ask: anyone else here ever heard it? I'd've guessed JCL came first, since PL/I was still in development as of December 1964 per the Wikipedia page. But this is the right place to get some answers (or at least opinions)! --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I vs. JCL
> column 1 is reserved for carriage control. That seems to conflate source
> code with SYSPRINT.
It does seem to, but in fact PL/I supports source listing formatting using ANSI
carriage control.
"The MARGINS option specifies which part of each compiler input record contains
PL/I statements, and the position of the ANS control character that formats the
listing, ..."
-- PL/I P/G
Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Paul Gilmartin
Sent: Monday, September 27, 2021 5:43 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: PL/I vs. JCL
On Mon, 27 Sep 2021 15:42:35 -0700, Charles Mills wrote:
.
>
>//SYSIN DD DATA,DLM=xx solves the /* in column 1 problem.
>
+1
In one case I resorted to an exhaustive search to find a digraph
not occurring in a NETDATA sysin. Ugh!
>PL/I supports specifiable margins, so PL/I source can start in column 1.
>
Which is small solace to the programmer adopting existing sout\rce code.
An earlier ply, not quoted here, asserted that column 1 is reserved for carriage
control. That seems to conflate source code with SYSPRINT.
A co-worker once supplied some Rexx, all indented one column, presumably
to avoid the "/*" problem. Didn't work under OMVS, which appears to have
a restriction (undocumented) that "/* Rexx ..." begin in col. 1.
>I recall that the /* is a hardware feature of some card readers. I believe a
>2540 card reader generated some special status (unit exception?) when it
>read a card with /* in the first two columns, so one might ask "which came
>first: JCL or the hardware feature?"
>
Does TSO honor "ALLOCATDE DD(SYSUT1) DSN(*) DLM('xx') ... ?
The DLM must be 2 characters in JES3 and up to 8 in JES2 (Conway again).
Underreaching. It should be long enough to support a random number of
cryptographic strength.
>-Original Message-
>From: Phil Smith III
>Sent: Monday, September 27, 2021 3:09 PM
>
>A friend writes:
>
(As in: "Doctor, my friend thinks she might ..."?)
>In a conversation elsewhere I mentioned the oops between JCL using /* as end
>of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had
>to start in column 2 to prevent a comment from being interpreted as JCL.
>Oopsie. Does anyone remember which came first? There was some rumor that I
>no longer remember that one group didn't like the other group so some of
>this done on purpose.
>
Conway's Law, an IBM guiding principle, escalated to bitter conflict.
But, yes, fact checking needed.
-- 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: PL/I vs. JCL
On Mon, 27 Sep 2021 15:42:35 -0700, Charles Mills wrote:
.
>
>//SYSIN DD DATA,DLM=xx solves the /* in column 1 problem.
>
+1
In one case I resorted to an exhaustive search to find a digraph
not occurring in a NETDATA sysin. Ugh!
>PL/I supports specifiable margins, so PL/I source can start in column 1.
>
Which is small solace to the programmer adopting existing sout\rce code.
An earlier ply, not quoted here, asserted that column 1 is reserved for carriage
control. That seems to conflate source code with SYSPRINT.
A co-worker once supplied some Rexx, all indented one column, presumably
to avoid the "/*" problem. Didn't work under OMVS, which appears to have
a restriction (undocumented) that "/* Rexx ..." begin in col. 1.
>I recall that the /* is a hardware feature of some card readers. I believe a
>2540 card reader generated some special status (unit exception?) when it
>read a card with /* in the first two columns, so one might ask "which came
>first: JCL or the hardware feature?"
>
Does TSO honor "ALLOCATDE DD(SYSUT1) DSN(*) DLM('xx') ... ?
The DLM must be 2 characters in JES3 and up to 8 in JES2 (Conway again).
Underreaching. It should be long enough to support a random number of
cryptographic strength.
>-Original Message-
>From: Phil Smith III
>Sent: Monday, September 27, 2021 3:09 PM
>
>A friend writes:
>
(As in: "Doctor, my friend thinks she might ..."?)
>In a conversation elsewhere I mentioned the oops between JCL using /* as end
>of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had
>to start in column 2 to prevent a comment from being interpreted as JCL.
>Oopsie. Does anyone remember which came first? There was some rumor that I
>no longer remember that one group didn't like the other group so some of
>this done on purpose.
>
Conway's Law, an IBM guiding principle, escalated to bitter conflict.
But, yes, fact checking needed.
-- gil
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/I vs. JCL
Adding a dummy first line because LISTSERV rejected this post because it thought it was a command, not a message ... //SYSIN DD DATA,DLM=xx solves the /* in column 1 problem. PL/I supports specifiable margins, so PL/I source can start in column 1. My earliest S/360 memories are from 1968, and both JCL and PL/I were already around, so no help there. My introduction to S/360 came from PL/I aficionados, and I remember hearing that the column 2 margin avoided this conflict, but I don't recall any "which came first" or "my camp versus your camp" hostility. I recall that the /* is a hardware feature of some card readers. I believe a 2540 card reader generated some special status (unit exception?) when it read a card with /* in the first two columns, so one might ask "which came first: JCL or the hardware feature?" I don't know the 14xx series at all. Did it use /* as control card end-of-file? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Monday, September 27, 2021 3:09 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PL/I vs. JCL A friend writes: In a conversation elsewhere I mentioned the oops between JCL using /* as end of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had to start in column 2 to prevent a comment from being interpreted as JCL. Oopsie. Does anyone remember which came first? There was some rumor that I no longer remember that one group didn't like the other group so some of this done on purpose. I've never heard this, which proves nothing much, but leads me to ask: anyone else here ever heard it? I'd've guessed JCL came first, since PL/I was still in development as of December 1964 per the Wikipedia page. But this is the right place to get some answers (or at least opinions)! -- 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: PL/I vs. JCL
PL/I is free format. The default is 2 - 72, but there is a compiler option to change that (SORMGIN). Joe On Mon, Sep 27, 2021 at 5:09 PM Phil Smith III wrote: > A friend writes: > > In a conversation elsewhere I mentioned the oops between JCL using /* as > end > of dataset and PL/I using /* */ for comment brackets - meaning that PL/I > had > to start in column 2 to prevent a comment from being interpreted as JCL. > Oopsie. Does anyone remember which came first? There was some rumor that I > no longer remember that one group didn't like the other group so some of > this done on purpose. > > > > I've never heard this, which proves nothing much, but leads me to ask: > anyone else here ever heard it? I'd've guessed JCL came first, since PL/I > was still in development as of December 1964 per the Wikipedia page. But > this is the right place to get some answers (or at least opinions)! > > > > > -- > 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: PL/I vs. JCL
PL/I uses column one for a carriage control while JCL requires a / in column one, so this was never a problem On Mon, Sep 27, 2021 at 10:09 PM Phil Smith III wrote: > > A friend writes: > > In a conversation elsewhere I mentioned the oops between JCL using /* as end > of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had > to start in column 2 to prevent a comment from being interpreted as JCL. > Oopsie. Does anyone remember which came first? There was some rumor that I > no longer remember that one group didn't like the other group so some of > this done on purpose. > > > > I've never heard this, which proves nothing much, but leads me to ask: > anyone else here ever heard it? I'd've guessed JCL came first, since PL/I > was still in development as of December 1964 per the Wikipedia page. But > this is the right place to get some answers (or at least opinions)! > > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PL/I vs. JCL
A friend writes: In a conversation elsewhere I mentioned the oops between JCL using /* as end of dataset and PL/I using /* */ for comment brackets - meaning that PL/I had to start in column 2 to prevent a comment from being interpreted as JCL. Oopsie. Does anyone remember which came first? There was some rumor that I no longer remember that one group didn't like the other group so some of this done on purpose. I've never heard this, which proves nothing much, but leads me to ask: anyone else here ever heard it? I'd've guessed JCL came first, since PL/I was still in development as of December 1964 per the Wikipedia page. But this is the right place to get some answers (or at least opinions)! -- 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
Ed Jaffe wrote: >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. "indefensible"? "unimpeachable"? What did you mean? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
z/OS Dataset Last Date Used Information
Hi, I am interested in acquiring information on the DASD Datasets, which were updated recently and to understand the resources utilization. Is there a Tool available in CBT or somewhere where I could use to provide me report on each DASD dataset which were updated today for an example. I am aware of DCOLLECT and changeid Indicator and LREF, as I currently extract the information from there but interested in other options as well, if they are available. My program checks for CHGID and LREF and if LREF is today's date and CHGID is 'YES' then probability is that it was changed today for Output. Any expert advise would be appreciated. Thank You in advance, Regards, Jasi Grewal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Tape Tools reporting and Splunk
I was wondering if anybody is routing any of their Tape tools reporting to Splunk? Especially interested if you are doing this without using some other third party software product. Regards, John Benik This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: a Custom migration from CA scheduler to IBM workload scheduler on z/OS
Hi I was external trainer for IBM since 1989 on TWS z/OS and TWS Distributed My catalog of training is IWSD 9.50 user IWSD 9.50 Administration ZWS 9.50 user ZWS 9.50 Administration Delta ZWS/IWS Distributed DWC for ZWS And my second business is the migration of every scheduler to every scheduler My training are only on remote since COVID Cordialement, Best regards Philippe TESSIER Systèmes et Documents 30, rue Vincent Moris 92240 Malakoff FRANCE > Le 27 sept. 2021 à 19:49,a écrit : > > FYI, for anyone interested. > > > > From: Brian Miller > Sent: Monday, September 27, 2021 10:55 AM > To: David Mingee > Subject: a Custom migration from CA scheduler to IBM workload scheduler on > z/OS > > > > Hi David, > > > > Hope you and the family have weathered theses strange times? > > > > I received this request from another training company that we work with. In > fact they are an IBM Partner. > > > > 'We received a request from IBM for a SME call next week to discuss a Custom > migration from CA scheduler to IBM workload scheduler on z/OS for a group of > about 70 students that are migrating from CA to IBM Workload scheduler 9.5 > on Z/OS.' > > > > I believe the course was retired by IBM some time ago. > > > > Do you or any of your colleagues have the knowledge to deliver this? > > > > Thanks, > > > > Brian > > 1-201-214-9910 > > > > > -- > 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
FW: a Custom migration from CA scheduler to IBM workload scheduler on z/OS
FYI, for anyone interested. From: Brian Miller Sent: Monday, September 27, 2021 10:55 AM To: David Mingee Subject: a Custom migration from CA scheduler to IBM workload scheduler on z/OS Hi David, Hope you and the family have weathered theses strange times? I received this request from another training company that we work with. In fact they are an IBM Partner. 'We received a request from IBM for a SME call next week to discuss a Custom migration from CA scheduler to IBM workload scheduler on z/OS for a group of about 70 students that are migrating from CA to IBM Workload scheduler 9.5 on Z/OS.' I believe the course was retired by IBM some time ago. Do you or any of your colleagues have the knowledge to deliver this? Thanks, Brian 1-201-214-9910 -- 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 BatchPipes in the z/OS Base (was: ... Pipes ...)
Gil wrote: >On Mon, 27 Sep 2021 07:26:51 -0500, Hobart Spitz wrote: >>I'm going to pivot here. I'm putting my support behind putting BatchPipes >>in the z/OS base (rather than just Pipes). If you agree, please >>write/support such a requirement and/or educate your management to get >>interested. BatchPipes includes BatchPipesWorks, a not so current, but >>still highly useful, version of TSO Pipelines. >> >Is an RFE for an update required? Conway's Law. Great question. I guess it would depend on whether the were a lot of current BatchPipes customers needed the missing builtin stages and/o fix(es) or whether it was more important to get BatchPipes in the z/OS base. It might also depend on how much additional work would be required to get a more current version of Pipes into BatchPipes, and whether the staff, skills, and funding were available. IMHO, the update would delay the benefits of BatchPipes in the base (especially global warming mitigation), and not be important to current BatchPipes customers. In my estimation, BatchPipesWorks has 90% of the needed stages and 99% of the fix(es) as would be in an up to date version of TSO Pipelines. I find the IBM decision making process obscure, so these may not be the considerations that affect the final decision. AFAIK, there is only one person now working on Pipes, so I must be missing something in applying Conway's law. > Does BatchPipes support connecting two Classic modules with an intervening > small Pipeline filter? How? Is a coordinated third job needed? Let me clarify some terms, answer you questions in the process, and clarify my previous post: Inter-JOB pipe - This is a ppe that let's two JOB pass records from one to the next thru memory. The BatchPipes subsystem(s) is/are required. AFAIK: There are no obvious limitations to the topology. You can have multiple JOB connected in a single "stream", split and/or join streams, or even have loop(s). In this respect, it is similar to the PIPE command, except that the record flow with split and rejoined streams may not be predictable between JOBs. Half Pipe Fitting or Intra-STEP pipe - This is a series of Pipes stages that operate between a program in a step and the storage medium. Intra-JOB pipe - This would be similar to VIO; it doesn't exist otherwise. I think it would be a great feature. Hence I incorrectly used the term to refer to Half Pipe Fittings in a generic sense. Apologies for any confusion. AFAIK, and if I understood your question, connecting two classic programs in the same step with a series of Pipes stages may not be possible now, at least without resorting to Assembler. I think the main reason is the potential for DD name conflict, both in the TIOT (DD name table) and in JCL. Most COBOL programs require SYSOUT, so the output could be intermixed. Much less tolerable, I suspect, would be a common DD (e.g. OUTPUT) conflict. Putting a record that doesn't belong between two records that must be consecutive would probably be a disaster. That said, it may be possible for a REXX filter to start two COBOL (e.g.) programs as subtasks (address attach ... , etc.) and feed and receive their records via an Assembler(?) Pipe Fitting. You would have to resolve any DD name conflicts. I don't think anyone has contemplated the capability for creating multiple TIOTs in a single step, let alone how to reference them in JCL. I think such things have been done under CMS using Assembler. Also: pipe - a generic connection, in memory, between two processes or tasks. Pipes - the TSO/CMS Pipelines software, singular. Pipe - a specific instance of Pipes. PIPE - the command that runs Pipes. 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 27, 2021 at 9:10 AM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 27 Sep 2021 07:26:51 -0500, Hobart Spitz wrote: > > >I'm going to pivot here. I'm putting my support behind putting BatchPipes > >in the z/OS base (rather than just Pipes). If you agree, please > >write/support such a requirement and/or educate your management to get > >interested. BatchPipes includes BatchPipesWorks, a not so current, but > >still highly useful, version of TSO Pipelines. > > > Is an RFE for an update rrequired? Conway's Law. > > Does BatchPipes support connecting two Classic modules with an intervening > small Pipeline filter? How? Is a coordinated third job needed? > > >The reasons are: [Snip! See the archive.] > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.e
Re: The Business Case for BatchPipes in the z/OS Base (was: ... Pipes ...)
On Mon, 27 Sep 2021 07:26:51 -0500, Hobart Spitz wrote: >I'm going to pivot here. I'm putting my support behind putting BatchPipes >in the z/OS base (rather than just Pipes). If you agree, please >write/support such a requirement and/or educate your management to get >interested. BatchPipes includes BatchPipesWorks, a not so current, but >still highly useful, version of TSO Pipelines. > Is an RFE for an update rrequired? Conway's Law. Does BatchPipes support connecting two Classic modules with an intervening small Pipeline filter? How? Is a coordinated third job needed? >The reasons are: [Snip! See the archive.] -- gil -- 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 (was: ... Pipes ...)
I'm going to pivot here. I'm putting my support behind putting BatchPipes in the z/OS base (rather than just Pipes). If you agree, please write/support such a requirement and/or educate your management to get interested. BatchPipes includes BatchPipesWorks, a not so current, but still highly useful, version of TSO Pipelines. The reasons are: 1. The audience that could benefit from BatchPipes in the base is much larger than that of TSO Pipes in the base. The former includes organizations that: - Have a limited batch window or want to reduce JOB run times. - Are constrained on developer resources. - Want to reduce hardware requirements. - Require quick resolution to production problems. - Have a policy to reduce their carbon footprint and/or their contribution to the climate crisis. 2. It is unrealistic to expect wide buy-in for TSO Pipes since most z/OS sites are highly dependent on JCL. 3. BatchPipes in the z/OS base would be the biggest enhancement to JCL since it (JCL) came into existence. 4. BatchPipes in the base would improve the competitiveness of z/OS. 5. IBM, vendors, and customers would benefit from the capability by being able to write quicker running, more general, less complicated JCL, knowing that BatchPipes would be available on all target systems. 6. All parties could potentially benefit from having the PIPE command available on all target systems. 7. BatchPipes fittings could enhance and extend existing programs and utilities with a consistent, intuitive, and uncomplicated control language. Too many utilities have unique, inconsistent, and/or complex control languages. 8. Contribute to global warming mitigation by reducing electricity usage due to processors, storage hardware and cooling. This is more significant with BatchPipes as there is likely to be a larger impact in a shorter amount of time than with just Pipes alone. The latter would be adopted more slowly and less broadly. Climate crisis mitigation efforts may be exempt from the rumored requirement that IBM is legally barred from offering software at a loss. (IMHO, the huge number of competitors to IBM in today's market, suggests that any such requirement is obsolete and should be removed.) 9. There would be some portability between z/VM and z/OS. 10. Despite wide support, Pipes requirements have not budged for decades . Anyone so inclined, is welcome to submit such a requirement, adapt my Pipes requirement, and/or work with me on a new requirement. Of course, if you agree, vote for the requirement. Can the current Pipes requirement be construed to support BatchPipes? Is it too much to expect BatchPipes to be added to the z/OS base without the delay of waiting for requirement(s), voting, and acceptance. Alternatively, BatchPipes and the REXX Compiler, possibly along with other software, could be packaged together as a combined product, perhaps with a performance or global warming mitigation theme . Another possibility would be to offer BatchPipes Light, where the intra-JOB piping was offered free or in the base. Half pipe fitting might be a loss-leader to attract customers to the full product. As a developer, I love REXX and I love Pipes. Together, they are programmer heaven, more so than OO. 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 essentially is an enhancement that allows Pipes stages to run on most DDs between the program and the storage media. I don't like BatchPipes. They require opsys or sysprog assistance and are too much trouble to use. They support inter-JOB piping which requires a subsystem and makes the real valuable part (Half Pipe Fittings) complicated and hard to use. Since I almost never use JCL, I have no use for them. I can, however, see their use and, as listed above, their value to the z/OS community as a whole. 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 s
