|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.