RE: Optimizing File I-O in RPG IV/I-Series - continued

Sorry - 

My mistake. The original post yesterday was. I grabbed the wrong email
address for today's follow-up.

My apologies

Jim




Once a job is fouled up, anything done to improve it makes it worse. 
Finagle 


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Thursday, 24 November 2005 12:48
To: Midrange Systems Technical Discussion
Subject: Re: Optimizing File I-O in RPG IV/I-Series - continued


Jim,

Why did you switch this to MIDRANGE-L?  Seems to me that it was on-topic

for RPG400-L where it started. Why the switch?

> Working with 249,271 records, the READE loop changed those records in
70
> seconds (processor time).
> Working with the same number of records, using READ but leaving BLOCK
as
> it's default - 72 seconds
> Working with the same number of records, using READ and adding
> BLOCK(*NO) - 72 seconds

Turning blocking off with BLOCK(*NO) is the wrong direction to go.  The 
whole reason you want to use READ instead of READE is to make blocking 
possible to improve performance.  Why would you specify BLOCK(*NO) that 
seems to defeat the purpose.

I'm guessing by your results that it was turned off by default (probably

because it's an update file).

Here are some things I'd play with:

a) Try doing the READ op-codes on a separate, read-only, file.  Specify 
BLOCK(*YES) on that file.

b) Have a second copy of the file open to do the updates (assuming that 
they're going to the same file.)

c) Try using SETOBJACC to bring the file into memory. This'll speed up 
access to it.

> I ran these benchmarks on our development machine, which has a fairly
> constant load. I was surprised READ didn't show me any advantage, even
> though many of you suggested that it would.

The only advantage to READ over READE is that READ uses blocking. When
you 
turn off blocking, it won't improve performance!!