[TUHS] Re: Perkin-Elmer Sort/Merge II vs Unix sort(1)

[Paul Winalski <paul.winalski@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2541 bytes --]

On Sat, Jan 18, 2025 at 10:17 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Sat, Jan 18, 2025 at 04:51:15PM +0200, Diomidis Spinellis wrote:
> > But I can't stop thinking that, in common
> > with the mainframes these programs were running on, they represent a
> mindset
> > that has been surpassed by superior ideas.
>
> I disagree.  Go back and read the reply where someone was talking about
> sorting datasets that spanned multiple tapes, each of which was much
> larger than local disk.  sort(1) can't begin to think about handling
> something like that.
>
> I have a lot of respect for how Unix does things, if the problem fits
> then the Unix answer is more simple, more flexible, it's better.  If
> the problem doesn't fit, the Unix answer is awful.
>
> cmd < data | cmd2 | cmd3
>
> is a LOT of data copying.  A custom answer that did all of that in
> one address space is a lot more efficient but also a lot more special
> purpose.  Unix wins on flexibility and simplicity, special purpose
> wins on performance.
>

Another consideration:  the smaller System/360 mainframes ran DOS (Disk
Operating System) or TOS (Tape Operating System, for shops that didn't have
disks).  These were both single-process operating systems.  There is no way
that the Unix method of chaining programs together could have been done.

OS MFT (Multiprogramming with a Fixed number of Tasks) and MVT
(Multiprogramming with a Variable number of Tasks) were multiprocess
systems, but they lacked any interprocess communication system (such as
Unix pipes).

True databases in those days were rare, expensive, slow, and of limited
capacity.  The usual way to, say, produce a list of customers who owed
money, sorted by how much they owed would be:

[1] scan the data set for customers who owed money and write that out to
tape(s)

[2] use sort/merge to sort the data on tape(s) in the desired order

[3] run a program to print the sorted data in the desired format

It is important in step [2] to keep the tapes moving.  Start/stop
operations waste a ton of time.  Most of the complexity of the mainframe
sort/merge programs was in I/O management to keep the devices busy to the
maximum extent.  The gold standard for sort/merge in the IBM world was a
third-party program called SyncSort.  It cost a fortune but was well worth
it for the big shops.

So the short, bottom line answer is that the Unix way wasn't even possible
on the smaller mainframes and was too inefficient for the large ones.

-Paul W.

[-- Attachment #2: Type: text/html, Size: 3108 bytes --]