One post implied to me to the following logic. KEY SETLL FILE IF NOT %NOTFOUND(FILE) KEY CHAIN FILE ENDIF IF NOT %NOTFOUND(FILE) * Process record ENDIF This would actually be slower than only CHAINing. The SETLL process is imbeded in the CHAIN. This code is in effect doing SETLL twice. A CHAIN resulting in not found is roughly the same overhead as SETLL. The data transfer part of CHAIN is the big hit.

Two ways you might be able to improve your performance. 1) If the 500,000 record file is being processed sequentially, it would help to use OVRDBF SEQ(*YES) NRECORDS(300) (parameter names are approximate) to force sequencial blocking. I have seen this make a major differance. 2) If the CHAINed to file is only 1000 records, preload this sequencially into an array and do LOOKUP *EQ. The trick to getting LOOKUP to perform well is to define the array as sequenced on the D spec and preload the entire array with high values before loading the data. The data, including unused trailing entries _MUST_ all be in sequence. LOOKUP of a sequenced array is much faster than an unsequenced array. This approach works very well when all or at least most records are CHAINed to one or more times.

:I have a program that processes a file of 500,000+ records which runs very slow. Each record chains to a another file to see if a record exists and does some calcs. Out of the total master file, there would be no more than 1000 successful hits on the secondary file. Before I go ripping this code apart (and converting it to RPGIV in the process), my expectation is that if I change the CHAIN to a SETLL and then chain on a successful hit that it should improve the performance considerably. Am I wrong in assuming that SETLL will just look at the "index" which should be in memory as opposed to CHAIN which most often requires an access to disk to retrieve the record?