Skip to main content
4 of 17
deleted 453 characters in body
rcgldr
  • 745
  • 3
  • 9

The fastest tape sorts were proprietary variations of polyphase merge sort that could take advantage of tape drives that could read backwards for 3 to 7 tape drives (for 8 or more tape drives, standard merge sort is faster). Since these were proprietary, the details have probably been lost.

Reading tape backwards reverses the order, so the distribution and merges operate on ascending and descending runs such that the end result is an ascending sorted file.

Another issue is if the input is from tape, after distribution, that tape has to be rewound and replaced with a working tape, unless there were enough tape drives that the input tape drive could be left idle and the remaining tape drives used to do the sort. For safety, the input tape drive would be write protected (it's write ring removed).

I wrote a 3 stack polyphase merge sort which is similar to what would have been used for tape drives that can read backwards. One complication is tracking run boundaries and when run size changes (increments or decrements) in the middle of a merge phase, but in the case of tape drives, the data block size would be fixed or at least some minimal size, allowing a small block (as opposed to a file mark which takes up space on a tape) to be used as an end of run indicator.

Another detail is an ideal initial distribution if the number of records is not known in advance, but if sorting was to be done on a regular basis, then some method of keeping track of a file's record count would be useful.

rcgldr
  • 745
  • 3
  • 9