Re: OPNQRYF Key Mismatches with RPG on versions 7.2 and beyond

On 2017-04-24 4:21 PM, Rob Berendt wrote:

Well, I tend to never code a new OPNQRYF application but in your case I
suspect that a simple recompile may help. Now, if you're using some dummy
file to match a particular format not found in nature then you might have
to adjust that DDS. For example, you're doing an OPNQRYF against some
join, with derived columns, etc. To get the rpg program to compile you
create a dummy file that looks like the end result. So if you've modified
your original application's key attribute and never updated the dummy file
then, yes, you would have to modify the dummy file in addition to
recompiling the rpg.

If the program was originally compiled with a file that matches the layout of the OPNQRYF result, then a recompile shouldn't be needed.

Otherwise, a PF should be created (or corrected) to match the layout of the OPNQRYF result, and the program should be recompiled to use that file at compile time. You can use the EXTDESC keyword to pick up the
compile-time PF.

What usually caused this problem was that people would do an OPNQRYF in their CL prior to compiling, expecting the compiler to pick up the external descriptions from the OPNQRYF. But an override to an OPNQRYF is only used when a file is actually opened. It isn't used by the functions that obtain the external descriptions. Depending on how the keys in the file are used in the program, the compiler might catch the error, but if something generic like CHAIN *LOVAL is used, then there's no coding error for the compiler to catch. The compiler just uses the wrong keys layout for the CHAIN.