Re: Blocking I/O (was: Expensive op codes)

I don't' come from the S/36 days, but from what I understand about blocking,
this can be a bad thing.

As I understand it, when you open a record for update on the AS/400 it locks
that record, and nothing more.  When you open a record for update on a blocked
file, wouldn't it tend to lock the whole block instead of just that one record?

Regards,

Jim Langston

Dan Bale wrote:

> I don't spend a lot of time reminiscing of my days on the S/36, but the one
> thing I miss and can't believe that the AS/400 never took advantage of was the
> ability of the S/36 to block records on update files.  Not only that, but the
> S/36 also took advantage of the double buffer option on the F-spec.  I
> benchmarked all this way back when.  If I remember correctly, an updated 
>record
> in the buffer not yet written out to disk was still available to other jobs;
> can't remember if the OS forced the write to disk or not.  Was this what was
> referred to as "single level store"?
>
> Your method of using an input file and an output file (with blocking on both)
> instead of a single update file is a design that I've used before when faced
> with a mass update of a very large file.  It's just a shame that, for whatever
> reason, IBM couldn't port that S/36 feature over to the AS/400.
>
> - Dan Bale
>

[Snippedy Snip Snip snip]

+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---