18 Jan
2025
18 Jan
'25
3:40 p.m.
On Sat, Jan 18, 2025 at 10:17 AM Larry McVoy <lm(a)mcvoy.com> wrote:
On Sat, Jan 18, 2025 at 04:51:15PM +0200, Diomidis
Spinellis wrote:
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.
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.