Re: Architectural implications of locate mode I/O

On 8/1/2024 2:01 PM, John Levine wrote:

According to Stephen Fuld  <sfuld@alumni.cmu.edu.invalid>:

On 7/31/2024 6:41 PM, Lawrence D'Oliveiro wrote:

On Sat, 6 Jul 2024 06:15:56 -0000 (UTC), Stephen Fuld wrote:
>

As you posted below, the whole PDS search stuff could easily be a
disaster.  Even with moremodest sized PDSs, it was inefficient has
hell.

>
Would locate mode have helped with this?

>
No.  The problem was that the PDS search was a linear search of records
on the disk drive i.e. typically multiple disk revolutions), and
furthermore, it required (until the fast PDS search came along) that the
host channel take action on each disk record checked, even the ones that
didn't match, including resending the search argument to the disk
controller.
>
This has nothing to do with locate mode.

 He's made it painfully clear that he doesn't understand the relative
speed of CPUs and disks, or the costs of multiple I/O buffers on
systems with small memories, particularly back in the 1960s when this
stuff was being designed. Nor how records in COBOL data divisions were
designed so implementations could read and write file records directly
from and to the buffers, and the IOCS of the era enabled that in COBOL
and other languages.

I believe you are right about that.

 Perhaps this would be a good time to stop taking the bait.

Perhaps you are right again, but something about hope springs eternal, and I couldn't resist pointing out the problems with the whole PDS search mechanism.

I thought
this silly argument was over a month ago.

Again, you may be right.  We'll see,
--
  - Stephen Fuld
(e-mail address disguised to prevent spam)