I'm going to pivot here. I'm putting my support behind putting BatchPipes
in the z/OS base (rather than just Pipes). If you agree, please
write/support such a requirement and/or educate your management to get
interested. BatchPipes includes BatchPipesWorks, a not so current, but
still highly useful, version of TSO Pipelines.
The reasons are:
1. The audience that could benefit from BatchPipes in the base is much
larger than that of TSO Pipes in the base. The former includes
organizations that:
- Have a limited batch window or want to reduce JOB run times.
- Are constrained on developer resources.
- Want to reduce hardware requirements.
- Require quick resolution to production problems.
- Have a policy to reduce their carbon footprint and/or their
contribution to the climate crisis.
2. It is unrealistic to expect wide buy-in for TSO Pipes since most z/OS
sites are highly dependent on JCL.
3. BatchPipes in the z/OS base would be the biggest enhancement to JCL
since it (JCL) came into existence.
4. BatchPipes in the base would improve the competitiveness of z/OS.
5. IBM, vendors, and customers would benefit from the capability by
being able to write quicker running, more general, less complicated JCL,
knowing that BatchPipes would be available on all target systems.
6. All parties could potentially benefit from having the PIPE command
available on all target systems.
7. BatchPipes fittings could enhance and extend existing programs and
utilities with a consistent, intuitive, and uncomplicated control
language. Too many utilities have unique, inconsistent, and/or complex
control languages.
8. Contribute to global warming mitigation by reducing electricity usage
due to processors, storage hardware and cooling. This is more significant
with BatchPipes as there is likely to be a larger impact in a shorter
amount of time than with just Pipes alone. The latter would be adopted
more slowly and less broadly. Climate crisis mitigation efforts may be
exempt from the rumored requirement that IBM is legally barred from
offering software at a loss. (IMHO, the huge number of competitors to IBM
in today's market, suggests that any such requirement is obsolete and
should be removed.)
9. There would be some portability between z/VM and z/OS.
10. Despite wide support, Pipes requirements have not budged for
decades .
Anyone so inclined, is welcome to submit such a requirement, adapt my Pipes
requirement, and/or work with me on a new requirement. Of course, if you
agree, vote for the requirement. Can the current Pipes requirement be
construed to support BatchPipes? Is it too much to expect BatchPipes to be
added to the z/OS base without the delay of waiting for requirement(s),
voting, and acceptance.
Alternatively, BatchPipes and the REXX Compiler, possibly along with other
software, could be packaged together as a combined product, perhaps with a
performance or global warming mitigation theme . Another possibility would
be to offer BatchPipes Light, where the intra-JOB piping was offered free
or in the base. Half pipe fitting might be a loss-leader to attract
customers to the full product.
As a developer, I love REXX and I love Pipes. Together, they are
programmer heaven, more so than OO. 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 essentially is an
enhancement that allows Pipes stages to run on most DDs between the program
and the storage media.
I don't like BatchPipes. They require opsys or sysprog assistance and are
too much trouble to use. They support inter-JOB piping which requires a
subsystem and makes the real valuable part (Half Pipe Fittings) complicated
and hard to use. Since I almost never use JCL, I have no use for them. I
can, however, see their use and, as listed above, their value to the z/OS
community as a whole.
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.
The list goes on.
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. All data is passed in locate-mode.
One of our developers had this crazy idea to convert all our JCL and COBOL
to REXX and Pipes. That's not happening, ever. 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 the COBOL had been over-maintained and was filled with lots 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; plus the important code interacts in two or more separate
modules. You can't know what a step is doing without knowing about both
the JCL and the program. BatchPipes Fittings and the PIPE command put
everything together, visible at once.
BatchPipes Fittings are the greatest enhancement to JCL since the first
days of OS/360 JCL in the 1960s.
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 fictional "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.
If you think BatchPipes could be helpful to your organization in some way,
talk it up with anyone who could move it forward in your organization. Try
to get it installed.
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
