Thank you for "PIPing" up on this! :) One thing to note, the PIPE command is part of the Base NetView product, you do not have to add SA to get it.
Al Nims Systems Admin/Programmer 3 UFIT University of Florida (352) 273-1298 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Thursday, November 16, 2017 4:30 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [TSO-REXX] Fwd: Pipelines in the z/OS base. Not sure where this fits in to the discussion, but Netview System Automation has a built-in pipes function. So we see messages like these: AOF570I 00:39:48 : ISSUED "PIPE SAFE AOFMSAFE | EDIT /AFTER 00:00:03,MVS $A/ N JOBNUM N /;S/ N JOBNUM N | NETVIEW" FOR MVSESA MVSESA - MSGTYPE IS $HASP100 AOF570I 01:04:11 : ISSUED "PIPE SAFE AOFMSAFE | EDIT FWDLINE 1 PARSE /,/ SKIPTO /DSNAME=/ W1 SUBSTR 8.* WL | EDIT /MVS S DB2ALOG,ALOG=/ N W1 N | LOGTO NETLOG | NETV" FOR SUBSYSTEM DA20MSTR - MSGTYPE IS DSNJ003I I'm not an SA guy, so I can't comment on the function in any detail. Just pointing out that it's included with the product on z/OS. . . 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 Paul Gilmartin Sent: Thursday, November 16, 2017 10:13 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: [TSO-REXX] Fwd: Pipelines in the z/OS base. On 2017-11-16, at 06:48:09, Hobart Spitz wrote: Cross posted to IBM-MAIN: > > The early versions of UNIX were written on small machines (32K?!), > with slow/small disk drives. Writing temporary results out to disk > was too slow and inefficient, so they came up a pipe operator ( | ), > which connected the input of one command to the output of the previous > one, thus avoiding physical I/O.. E.g. *ls | wc*. The data passed > thru an in-memory buffer with both commands running, and UNIX > dispatching each as needed. It also allowed intermediate results to > be very much larger than the available disk space, since those intermediate > results didn't have to be written to disk. > Sometimes. Otherwise, in those early days, real memory was often the constraining factor so the piped implementation had performance inferior to using a temporary file because of paging overhead. > ... The original questioner thought > I was pulling his leg (since one could do that with a single character > in > UNIX) and he had left before I was done. > Yup. Pipelines is not quite so terse. UNIX: foo <file1 | bar >file2 Pipelines: PIPE < file1 | foo | bar | > file2 > If you have any doubt about the usefulness of Pipes, take a poll of > your z/VM friends. They would tell you that they couldn't live > without Pipes, not because z/VM otherwise lacks anything, but because > Pipes is so powerful and efficient. > Not entirely true. CMS is grievously deficient in any support for concurrency. In consequence, any CMS command stage suspends the entire remainder of the pipeline while the CMS stage runs. So, Piplines reinvented many of the classic CMS wheels (it often did better). I hope pipelines on z/OS can employ ATTACH to avoid such redundancy. CMS pipelines is not well integrated with classic CMS commands. While the output of a CMS command can be connected to a Pipeline stage, a Pipeline stage can not be connected to the input of a CMS command. A question I have often asked, and usually been misunderstood is, "Can a Pipeline be connected to a DDNAME of a classic z/OS utility?" "Sure, Pipelines has a DD driver." answers a different question. That assumes that DD has been ALLOCATEd to a data set. But how can I connect a Pipeline to SYSUT1 or SYSUT2 of a classic command? I imagine the recherché approach: SYSCALL pipe connect a Pipeline to the input descriptor of the pipe. BPXWDYN ALLOC SYSUT1 to the output descriptor of the pipe SYSCALL pipe BPXWDYN ALLOC SYSUT2 to the input descriptor of that pipe connect a pipeline to the output descriptor of that pipe somehow invoke a utility. I suppose that could all be encapsulated in a Rexx stage. OS/360 had a design integrity with I/O abstraction better than that of CMS. I hope Pipelines for z/OS doesn't ignore that. -- 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
