RE: Buffering and single level store (was RE: chain problem)

> -----Original Message-----
> From: rpg400-l-bounces@xxxxxxxxxxxx / CWilt@xxxxxxxxxxxx
> Sent: Friday, August 13, 2004 1:08 PM
>
> After reading your other post and giving it some more thought.
> I'd have to say that the blocking is being done by  "above"
> the OS and the single level store.
>
> But that leads to the question: with all the technology (caching)
> in the OS and in the hardware, shouldn't we be able to turn
> off the RPG blocking without detrimental impact?
>
> Seems like the answer should be yes, but if I recall correctly
> recent posts have mentioned that blocking still provides an
> improvement.  I wonder why this is so.  Maybe just less overhead
> since there's less calls to the OS?

I am really tempted to just say "Why ask why? It just should, darnit!"  How
is it that the S/36 could be so far superior in managing data in memory
buffers?  You NEVER had this problem on the S/36, it just knew that what was
on that shiny platter was not as current as what was sitting somewhere in
memory and it got it.  Whether such action was effected by flushing the data
in memory to disk or the OS just went to get the data where it was in
memory, I'm not sure (but I seem to recall using a utility, sort of like a
Norton Utilities DISKEDIT, to view the contents of the data file while an
interactive udpate was taking place.  Another application does a chain to
the file where a record was updated in the first session.  The "DISKEDIT"
showed data prior to update, but the chain showed the updated record in
memory).  Maybe some of the old school can remember this:

     FCUSMAS  UP  F9984 256 2          DISK

Not positive on where the double-buffer '2' code went, but that 9984 was the
block size (had to be whole increments of record size), and 256 was the
record size.  Of all the things I've forgotten about the S/36, this topic is
not one of them!

Gotta get my ire back down before the weekend!

db