Gil,
I think you are grievously conflating style and content.
In the olden days, SORT wasn't capable of much beyond sorting (if you wanted to
take advantage of doing something else whilst you were processing the data,
this was the hey-day of the EXIT, Assembler-only). Mainly, applications people
would use multiple programs and multiple SORTs ("just sort it in descending
order, then manipulate, then put it back in the original order") and indeed
some people still suggest exactly those "old" solutions today.
Now, since the data is being SORTed anyway, how about the capability to carry
out extensive manipulations whilst that is going on? One SORT, one pass of the
data? More efficient, yes?
For sure, it would be nice to be able to "pipe" output from REPRO to the
SORTIN. It would not be nice having something other than REPRO which does not
benefit from the internal knowledge to make the process zippy, and it would not
be nice to have whatever that is having a whole bunch of coding possibilities,
given that you would replicate what is already available in DFSORT and which
would be used for the sequential datasets anyway (would there be benefit in
piping those just for the heck of it?).
Now, what is the practical alternative, for an application programmer, at 99.9%
of Mainframe sites, with all their established procedures? So you have to come
up with one, and it will need to be as performant and robust and maintainable
(you don't want X tools with X syntaxes where each is supposed to produce the
same output) as what exists, and then you still have a long, hard, argument to
win people over (assuming that you can get those prerequisites done).
That is not done just by flashing some technical words around, as I'm sure you
know. So, something concrete and argued such that application programmer and
management can evaluate it, and you could be on to a winner. Remember that
DFSORT has two places to "post-process" data (OUTREC and OUTFIL) and you'll
need to cater for that as well, and remember to support multiple exits (which
would mean you don't have to cover absolutely everything).
And then since it would be only "reinventing" if it were to merely match DFSORT
performance, then you're going to have to better that performance.
A couple of weekends, and we can see a POC?
Just to note, the two tasks which process the two inputs to JOINKEYS
effectively "pipe" to the main task.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
