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

Reply via email to