Re: Architectural implications of locate mode I/O

Lynn Wheeler wrote:

John Levine <johnl@taugh.com> writes:

By putting most of the logic into the printer controller, the 1403
was not just faster, but only took a small fraction of the CPU so
the whole system could do more work to keep the printer printing.

 
360 "CKD DASD" and multi-track search trade-off.

As you posted below, the whole PDS search stuff could easily be a
disaster.  Even with moremodest sized PDSs, it was inefficient has
hell.  Doing a linear search, and worse yet, doing it on a device that
was slower than main memory, and tying up the disk controller and
channel to do it.  It wasn't even sort of addressed until the early
1990s with the "fast PDS search" feature in the 3990 controller.  The
searches still took the same amount of elapsed time, but the key field
comparison was done in the controller and it only returned status when
it found a match (or end of the extent), which freed up the channel.
Things would have been much better if they simply used some sort of
"table of contents" or index at the start of the PDS, read it in, then
did an in memory search.  Even on small memory machines, if you had a
small sized index block and used something like a B-tree of them, it
would have been faster.




--
 - Stephen Fuld
(e-mail address disguised to prevent spam)