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
