Why haven't customers jumped on Pipes (CMS/TSO Pipelines), like they
should? Here are some possible answers:
1. They don't understand that Pipes is vastly superior to UNIX/USS style
piping and redirection when it comes to performance and flexibility. I
would not be surprised if IBM saw Pipes as a threat to hardware and
software sales.
- UNIX works on a character by character basis. Every single
character must go into the ALU and the inter-filter buffer.
IMHO, this is
why IBM had to add two cache levels as UNIX usage grew. Pipes works on
pointers, a.k.a. locate mode. There is no "buffering", except
for a small
number of documented and necessary cases, e.g. sort. Only
referenced data
goes into the ALU; if a record is skipped (e.g. drop) none of it goes
through the ALU. IBM might prefer UNIX because it sells more hardware,
among other reasons.
- Multi-stream piping is built into Pipes; it's not trivial but it's
workable. UNIX multi stream piping requires a lot more work,
relatively.
In Pipes, for example, most selection filters can trivially direct
unselected records to another stream.
- Pipes are deterministic. In most cases you can predict what is
happening and which filters are running. Under a *NIX system,
filters are
dispatched as buffers fill or empty, or as interrupted by preemption.
- Pipes, like most of z/OS and z/VM, use no embedded control
characters. The same filters that can process text data can
process binary
data. Yes, it can read and write ASCII data with the best of them.
2. IBM charges too much. (Not much explanation needed.) Could you
imagine a UNIX distribution without piping and redirection? I can't.
(Could you imagine a UNIX distribution without a C compiler? Like Pipes,
the REXX compiler, required for quality and performance production, is
optional and chargeable.)
3. Pipes has a bit of a learning curve, much less so with someone who
already knows UNIX piping. There are new filter names; the PIPE prefix is
mostly required; multiple streams have a unique syntax. Maybe customers
don't want to invest in training someone just to have them go to a z/VM
site. Further, the dispatcher has to know what you are doing. Issuing
ADDRESS TSO "..." in a user filter is technically unsupported; it does work
sometimes. You have to use the Pipes TSO filter to capture the output. So
your tried and true code snippets might not work in a user filter. That
said, you can do a whole heck of a lot before you need user filters.
4. Legal limits on subsidising one product by another or giving away
software. Maybe it's time to revisit the situation, with behemoths like
MicroSoft, Amazon, Google, etc. able to challenge IBM. Could the 1960s
consent decree be obsolete?
5. Maybe IBM is afraid that customers will come to love Pipes so much
that they want the best of breed. The z/OS version is a bit old and
buggy. Best of breed is that on lean, mean, and economical z/VM, where
many legacy systems run with minimal changes, and where they do so more
efficiently. Newer, USS systems could be ported to zLinux side-by-side
next to their ported legacy systems.
These are some "reasons" as I see them. I can think of others, but this
has gone on long enough.
For anyone new to Pipes, on z/OS or z/VM, be sure to include these
essential options on _every_ PIPE, CALLPIPE and ADDPIPE command: PIPE...
(LISTERR NAME progname.sigl) ... . (Caps are optional and usually not
used.) sigl is the line number, which you can hard code or supply at
runtime with a function:
Pipe: return "pipe (listerr name" ExecName"."ExecDD."sigl")"
Use case:
Pipe() "< input.data | stem records."
ExecName and ExecDD can be set at entry with parse source OpSys CallType
ExecName ExecDD .
OREXXMan
Q: What do you call the residence of the ungulate with the largest antlers?
A: A moose pad.
:-D
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.
REXX is the new C.
On Sun, Sep 7, 2025 at 4:37 PM Jon Perryman <[email protected]> wrote:
> On Sun, 7 Sep 2025 14:03:27 -0500, Mike Schwab <[email protected]>
> wrote:
>
> >Passing files in MVS requires reads and writes of each record that
> >continues at each stage.
> >
> >Pipes the data from the input goes through all programs before it writes.
>
> The million $ question is why haven't customers jumped on board with
> PIPEs? Can you replace your performance sysprog with PIPEs?
>
> Are you saying UNIT=VIO or in storage VSAM couldn't be used? Are you
> saying swap out and swap in won't be a problem?
>
> Let's pretend your automation product has PIPEs and you find it so easy
> that you ignore common sense. Do think a system going into panic can
> survive delays that didn't cause a problem during testing?
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
