It’s not very useful any more except for READV 0 I suppose; if it ever was very useful.
When frames were 512 bytes, with 500 usable for data, then an item could quite easily bleed over a single frame of course. If that FID was not already in memory, then it caused a frame fault, which results in IO. So a READV could in theory mean you could limit the frame faulting to the first frame of the item. Though that sounds more like bad design to me.I have no idea if that’s why it was implemented - it could have just felt like a good idea to someone at the time. Or perhaps they really did think that scenario through and see it had some practical performance improvement. My bet is on the “good idea” theory to be honest. Someone else may remember if there was any method behind the madness.
Three READVs in a row sounds more like someone was lazy, or didn’t really understand what they were doing - no disgrace really. Personally, I would never have used it I think.
In Reality, the frames were eventually - around 1984 or thereabouts - reverse mapped to the disk sectors. The disk spins only one way of course, so if it has 64 sectors per track, you can write frame 1 on sector 0, or frame 64 on sector 0, etc. This meant that if you asked for frame 1, and the disk head was on frame 5, the system would read frame 5, 4, 3, 2 ,1 into memory.
This was usually a great optimization because it was quite likely that after using frame 1, a program, would immediately ask for frame 2, which would be in memory. Think about SELECT READNEXT and English queries (it depends how frames are mapped to files of courses).
Track reads were also added, so that you got all the frames on a single disk track in one hit. Track reads could actually slow things down for some systems (usually poorly written), so you could turn them off. So READV had no practical value.
In Unix based systems, most implementations allow the underlying file system and kernel to manage cache etc. As algorithms get better and better at predicting disk access, this gets better and better of course. And nobody will be using hard drives these days for main working storage anyway. jBASE uses memory mapping for instance. These days the only performance problems the average system should have are poor algorithms. They can be fixed.
Jim