Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

On 19/05/2025 22:58, Stephen Fuld wrote:

On 5/19/2025 1:46 PM, Vir Campestris wrote:

On 19/05/2025 02:41, Stephen Fuld wrote:

>
It didn't make sense to, after executing the full track read, since the disk was positioned at the end of the track, and you had a good indication that it was a sequential file read, to start caching the next track in anticipation of the next full track read?

>
It might if the disk was idle. But if there is a queue from another process it probably will be better to do that instead.

 I presume you know that the 3880 controller did not do what today we call command queuing, so I think you were referring to a potential queue in the host.  That being the case, the controller doesn't know if there is a queue or not.  So given that, why not start reading record 1 on the next track.  If a request comes in, you can abandon the read to service the request - no harm, no foul.  If there isn't, and you subsequently get a request for that track, it's a big win.  The only potential loss is if you get a request for the track that was LRU and got pushed out of the cache.
 

The only IBM machine I've ever even touch was a PC/XT - so no, I didn't know. That makes sense.
My mainframe background goes back to the ICL 2900 at the beginning of the '80s. There were two families of disc controllers, one of which did clever stuff like retries for the host (I don't remember if it cached) and the other one was dumb and cheap. The dumb one was becoming more popular at the time when I discovered the realities of working in tech and had practice in CV writing...
Andy
--
Do not listen to rumour, but, if you do, do not believe it.
Ghandi.