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

In addition to the other tips detailed in this thread, one other new feature
comes to mind...  Files created via SQL DDL versus DDS can perform better
due to differences in how IBM implements data validation.  It seems that IBM
makes DDL files validate data as it is written, as opposed to as it is read.
Thim might not make much difference when performing mass updates, but a
typical application will generally read dozens of records for each
write/update....  There was an article describing this...

http://www.iseriesnetwork.com/resources/artarchive/index.cfm?fuseaction=view
article&CO_ContentID=20067&channel=

Eric DeLong
Sally Beauty Company
MIS-Project Manager (BSG)
940-297-2863 or ext. 1863



-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Jim Wiant
Sent: Tuesday, November 22, 2005 6:18 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: Optimizing File I-O in RPG IV/ I-Series


We have a series of programs that update files for assorted maintenance.
The time these programs are taking is becoming excessive.

In most cases, the RPG code is very simple.

Key     SETLL                   file
Key     READE                   file
        (Do until EOF)
        UPDATE          record
Key     READE                   file
        END DO

I don't see how the code can get might tighter. Is there any reasonable
compiling options/ CL overrides, etc. that could improve such a routine
when it
needs to process a large number of records? We're not opposed to
changing code, but if just a few H spec changes and/or compiling options
could gain
us a bit of performance, it would help us out.

I've tried a few of the basics (OPTIMIZE(*FULL), NoDEBUGIO, etc.) but
didn't see much of a change in my benchmarks.

Thanks for any help

Jim Wiant


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


This message has been sent from Foodstuffs (Auckland) Limited
("Foodstuffs").

The information contained in this message and or attachments 
is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged 
material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon, this 
information by persons or entities other than the intended 
recipient is prohibited. If you received this in error, 
please contact the sender and delete the material from any 
system and destroy any copies.

The views and opinions expressed in this message may be those
of the individual and not necessarily those of Foodstuffs, 
and are not given or endorsed by it.

Please note that this communication does not designate an 
information system for the purposes of the Electronic 
Transactions Act 2002.