Between V1R3M0 and V2R1M0 of OS/400, IBM seems to have changed the RPG/400 SETLL operation in such a fashion that it may affect the performance of certain applications. Under V1R3M0, it is perfectly acceptable to verify that a key exists by using SETLL with an indicator in columns 58-59. The V1R3M0 RPG Reference manual states that, "If you are only interested in verifying that a key actually exists, SETLL with an equal indicator (positions 58-59) is a better solution than a CHAIN operation in most cases." This is true and a great solution for V1R3M0 applications, because the SETLL operation doesn't produce a record lock for update files.
However, things get a little stickier with V2R1M0 when IBM adds the following line to the above description: "... Under special cases of a multiple-format logical file with sparse keys, CHAIN can be a faster solution than SETLL." At my company, where we develop on a V1R3M0 machine and implement on V2R1M0 systems, we have found this to be an understatement. In some applications where SETLL was used to verify key existence with certain multi-format logical files, application performance decreased significantly. In one instance, identical application code took 15 times longer (this is not a misprint) to run on a V2R1M0 machine than it did before. After rewriting the code to replace the SETLL with CHAIN, performance came back in line.
So, if you're having performance problems when you upgrade your system from V1R3M0 to V2R1M0, check your code for the presence of SETLL on multi-format logical files and rewrite accordingly. It may be a timesaver for you and your shop.
LATEST COMMENTS
MC Press Online