> On Jun 19, 2019, at 2:00 AM, Rob van der Heij wrote:
>> { stage1; stage2; stage3; } | stage4
>
> I understand this concatenates the output of the first three programs (in
> order?)
> and passes it as input to the fourth one. Cute. So what about input (it seems
> the
> first program in that set takes the input). So my pipeline would be
>
> .. stage1 | append stage2 | append stage3 | stage4 ..
>
Stages run in order, sharing input. So what isn’t consumed by
the first stage is available to the second, etc. But if a stage buffers
reads and doesn’t process the data, the effect is unpredictable.
Pipelines wins big here.
And anywhere in UNIX I miss Pipelines’ ability to process a
header then short-circuit the rest of the stream to output.
I was told, somewhere, that APPEND incurs a performance hit. I have
seen:
PIPE LITERAL Line three
| LITERAL Line two
| LITERAL Line one
| STAGE4.
Ugh! Terrible to read.
I ignore performance concerns and:
PIPE HOLE
| APPEND LITERAL Line one
| APPEND LITERAL Line two
| APPEND LITERAL Line three
| STAGE4
… the HOLE is so I can rearrange stages. Kinda like the practice
of not labelling Assembler instructions, but labelling DS 0H.
> Your mapping of the syntax is flawed. In your example the '|' connects the
> stages,
> just like the CMS Pipelines stage separator. The ';' (don't forget the last
> one)
> in combination with the { } forms a kind of input manifold.
>
Syntax silliness. “}” is a command (sort of), but without the last “:” it would
be just an argument to the prior command.
> ..t. CMS Pipelines has abstractions for TCP/IP and IUCV connections, so
> it is easy to compose a pipeline refinery that has multiple CMS users involved
> to do the work. The obvious reason would be to control access to data, but
> you could also use it to dispatch heavy tasks over workers (even on different
> systems). One z/OS you could also use BatchPipes to connect different parts of
> your application running in parallel.
>
And the CMS constraint is onerous here. On z/OS I can have many sessions
running concurrently, both batch and interactive, all on the same user ID.
I might have hoped that SFS would have removed half the obstacle, but the
other half remains. Limited concurrency, even within a single session.
— gil
