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

["Simon Coulter" <shc@xxxxxxxxxxxxxxxxx>]


Hello Dave,

The reason you see little difference in your two tests on NBRRCDS is that 
database will use the 
value specified on SEQONLY for NBRRCDS also.  Since you have indicated 
sequential processing DB 
knows that it can bring blocks into MS as well as your program buffer and it 
does so.  DB will 
double buffer at every opportunity.

NBRRCDS is useful in two cases:

1/ Where you are processing a file sequentially by key.  Keyed processing 
causes the compiler to 
turn off blocking.  But if you know the data is physically in key order then 
NBRRCDS will reduce 
I/O by ensuring the data is in MS. For example;

        OVRDBF SEQONLY(*NO) NBRRCDS(341)

2/ Where you want a smallish program buffer to limit possible data loss but 
want to reduce I/O 
by bringing large blocks from disk.  Provided your program can process the data 
and your system 
is not memory constrained you will not see page thrashing.  For example;

        OVRDBF SEQONLY(*YES 12) NBRRCDS(48)

Regards,
Simon Coulter.

«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
«» FlyByNight Software         AS/400 Technical Specialists       «»
«» Eclipse the competition - run your business on an IBM AS/400.  «»
«»                                                                «»
«» Phone: +61 3 9419 0175      Mobile: +61 0411 091 400           «»
«» Fax:   +61 3 9419 0175      mailto: shc@flybynight.com.au      «»
«»                                                                «»
«» Windoze should not be open at Warp speed.                      «»
«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»«»
//--- forwarded letter -------------------------------------------------------
> X-Mailer: Mozilla 4.61 [en] (WinNT; I)
> Date: Sat, 23 Oct 1999 11:17:37 -0700
> From: "Dave Murvin" <davem@drme.com>
> To: RPG400-L@midrange.com
> Reply-To: RPG400-L@midrange.com
> Subject: Re: Blocking I/O (was: Expensive op codes)

> 
> >From what I read in the manuals (see "Sequential-Only Processing" in DB@ UDB 
>for
> AS/400 Database Programming V4R4), a  News/400 article ("A Game Plan for
> Performance" Sept. 1999) and various postings, the difference between SEQONLY 
>and
> NBRRCDS is as follows:
> 
> NBRRCDS controls the number of records that are moved as a unit between 
>auxiliary
> storage and main storage.  You should only be using this keyword for physical
> files read sequentially and for input only logical files read sequentially 
>where
> the underlying physical file is ordered in the logical file sequence.  
>Otherwise,
> this can decrease performance due to buffers being flushed prematurely (read a
> big block of records, process a record, flush the big block of records, read a
> big block of records, etc.).
> 
> SEQONLY(*YES nnn) controls the number of records that are moved as a unit
> between  main storage and your programs internal buffers.
> 
> My tests reading (READ op code)  the million+ record physical file did not 
>show
> much difference using the NBRRCDS keyword.  (341 records is a 64K block).
> 
> OVRDBF SEQONLY(*YES 341)
>     Elapsed time 1:19, number of seconds 63
> OVRDBF SEQONLY(*YES 341) NBRRCDS(341)
>     Elapsed time 1:18, number of seconds 63
> 
> Same test with no overrides, using the default blocking of 4K buffer
>     Elapsed time 2:44, number of seconds 112
> 
> The News/400 article also said that the reason that READE is slower is that 
>the
> compiler translates READE into QDBGETK (Get by Key) Machine Interface (MI)
> program, which doesn't perform blocking.
> 
> --
> Dave Murvin
> DRM Enterprises, Inc.
> davem@drme.com

+---
| 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
+---