RE: RPG and BLOCK(*YES)

[Buck Calabro <Buck.Calabro@xxxxxxxxxxxx>]

>We have a file with 17,960,960 records.  We were
>doing some time trials on BLOCK(*YES).
>
>Here are my questions:
>When should you use BLOCK(*YES)?

I use blocking when I know the application will be reading sequentially.
This sometimes involves explicit ordering with FMTDTA.  This is an
architectural decision, really.  If I need to pass through all the records
to do something like tag them all "transmitted" or accumulate a total then
I'll definitely go the sequential route.

>Is there an overhead to blocking?  For example if
>I am only reading a couple of records, does it take
>overhead to load a huge chunk of data for a
>couple of records?

I think this is system overhead for the I/O adapter to fetch the data and
trasfer it to an OS/400 buffer.  RPG doesn't see the records until you ask
for them, so if the system fetches in 500 records as a block and your
program only reads one record before doing another CHAIN then the system
just fetched 499 records for naught.

>Should you use it when doing random chains all over the file?

I don't.

>Should you use it when doing a SETLL/READ but only
>reading a few records?  If not, then when is the
>cut over from when to use it and not to use it?

Being a performance question, there can be only one answer: (all together
now) "it depends."  <grin>

Say I have a customer master file and a toll call file where each customer
has 1000+ toll call records.  If I block the tolls file I might get some
performance benefit because (on average) I'm going to be processing whole
blocks except when I switch customers.  Then I'm discarding some portion of
my fetched block.  If the tolls file has 50 toll records per customer, my
blocking factor should be smaller, but I might still see a benefit.  At some
point, the time taken doing the block fetch outweighs the time saved by
having the records in memory.  It depends on the processing speed, the I/O
adapter speed and the disk speed as well as the size of the block.
  --buck