Re: Program Performance

Almost certainly you can improve performance.  Given the limited
information, the most obvious approach is to reduce the I/O to the
non-primary files that are updated / written.  You can do this through
SQL grouping functions or through proper looping in standard RPG.

Simple example  --  

==OLD WAY==
Read primary
DoU EOF
Chain to secondary file
increment secondary fields
Update secondary file
Read primary
EndDo

==IMPROVED WAY==

Read primary (in order of  secondary key - keyed file, OPNQRYF, etc)

Do Until EOF 
Set key, clear summary fields

DoUntil EOF or key changes
Increment summary fields
Read primary
EndDo

Chain secondary file
Increment secondary fields from summary fields
Update (or write if not found) secondary file
EndDo   (EOF)

In your case, you will save 600000 reads of the most populous
secondary file.  Obviously, it gets more complicated with multiple
files being updated, but this is the general idea.  If the files are
various levels of a common key structure, you could have a deeper loop
tree.  For the small file you could populate an array, update the
array as the primary is read, and then loop through the arrays and
update the files after the primary is completed.

Just some thoughts.  Find ways to reduce Disk IO; that is the main
performance hit.

Regards.

On Thu, 25 Nov 2004 02:55:20 +0530, Muralidhar Narayana
<muralidhar_narayana@xxxxxxxxxxx> wrote:
> I have a program(of type SQLRPGLE) which  reads IPXPMPX1 sequentially and for 
> every record in IPXPMPX1, it goes to IPX.FTMS, IPXPCDF1(outputfile) and 
> IPX.MAS for populating the different fields in the outfile.
> 
> The  number of records in these files are as follows:
> IPX.FTMS(3190 records)
> IPXPMPX1(728,099 records)
> IPX.MAS(445 records)
> IPXPCDF1(105560 records)
> 
> The program due to  more number of records , is taking more time around 2 
> hours.This program is not very fancy,0 normal read and write opcodes & with 
> some bounded SQL statements.
> I would like to check is there anyway I can increase the performance of the 
> program and reduce the time it takes to run.
> Thanks so much for your ideas.

-- 
Tom Jedrzejewicz
tomjedrz@xxxxxxxxx