|
We have a PF that has over two million records in it (and it grows daily), that uses a SETLL/READPE command. I know there has been much debate as of late on the use of these commands, and I wanted to present a bit of could for your perusal and suggestions.
That's odd! Your subject, and the above paragraph state that you're using READPE, but the code that you posted uses READE.
But, anyway, since you're updating each record, you won't see the benefits of record blocking ANYWAY, so whether you use READE or READ won't have much impact on performance.
midrange.com
#SRUPD BEGSR
TIME TIME6 6 0
*(SST22)
KEYT22 SETLL SST22
*IN99 DOUEQ *ON
KEYT22 READE SST22 99
99 LEAVE
MOVE '1' SRADNF
Z-ADD *DATE SRADDT
MOVEL TIME6 SRADTM
UPDATE RSST22
ENDDO
Note that this code is wrong. It uses *DATE in conjunction with the current time. If this program remains running past midnight, the date won't change, but the time will. Why not use the date returned by the TIME so that this doesn't happen?
However, that has nothing to do with performance. I can see ways to shave a few milliseconds off of the time:a) You're comparing *IN99 to '1' twice in the loop. Once in the DOU statement, and once on the LEAVE statement. By putting a "priming" read before the loop, and moving the existing READE to the end of the loop, you can eliminate the LEAVE statement and therefore check *IN99 only once. This'll make the code marginally faster. However, since checking an indicator is a very fast operation, the difference won't be a big one.
b) You could put the 3 fields that you're moving/z-adding into a data structure, and have another data structure to move into them. That way, you need only do one MOVE in the loop, and that'll be a little faster. Again, it'll only be a few milliseconds.
c) You could try reading directly into a DS. Depending on how many fields are in the file, this could make a difference, though it might make my previous suggestion (B) more difficult. You'd have to experiement to see which one makes a bigger difference.
Anyone have suggestions on how I can improve / optimize this code to reduce the wait times in this area down to something significantly less than five minutes?
The other suggestion (which might make the code much faster, I don't know) would be to replace this loop with an SQL UPDATE statement.
What I would do is experiment with each possible option and test how much of a difference it makes in the speed. (i.e. benchmark it) maybe use 10000 records copied from the original file into a test file to do the benchmarking with. Figure out which option gives you the best performance and then use that for the larger file.
That's usually the best way to improve performance -- test each option and see.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.
