<div dir="ltr"><div dir="ltr">On Sat, Jan 18, 2025 at 10:17 AM Larry McVoy <<a href="mailto:lm@mcvoy.com">lm@mcvoy.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sat, Jan 18, 2025 at 04:51:15PM +0200, Diomidis Spinellis wrote:<br>> But I can't stop thinking that, in common<br>
> with the mainframes these programs were running on, they represent a mindset<br>
> that has been surpassed by superior ideas.<br>
<br>
I disagree.  Go back and read the reply where someone was talking about<br>
sorting datasets that spanned multiple tapes, each of which was much<br>
larger than local disk.  sort(1) can't begin to think about handling<br>
something like that.<br>
<br>
I have a lot of respect for how Unix does things, if the problem fits<br>
then the Unix answer is more simple, more flexible, it's better.  If<br>
the problem doesn't fit, the Unix answer is awful.<br>
<br>
cmd < data | cmd2 | cmd3<br>
<br>
is a LOT of data copying.  A custom answer that did all of that in<br>
one address space is a lot more efficient but also a lot more special<br>
purpose.  Unix wins on flexibility and simplicity, special purpose<br>
wins on performance.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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:</div><div><br></div><div>[1] scan the data set for customers who owed money and write that out to tape(s)</div><div><br></div><div>[2] use sort/merge to sort the data on tape(s) in the desired order</div><div><br></div><div>[3] run a program to print the sorted data in the desired format</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Paul W.<br></div><div><br></div><div><br></div></div></div>