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

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.


Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: Mohan Eashver <mohankva@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 04/24/2017 04:15 PM
Subject: OPNQRYF Key Mismatches with RPG on versions 7.2 and beyond
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>



Hi All,

We are considering an OS upgrade from 7.1 to 7.3.

I was reading thru the release notes. Following is an exact excerpt from
the 7.2 release notes that caught my attention.

I am unable to understand the solution.

Is the recommended solution to simply Re-Compile the RPG that is called by
the CL that does the OPNQRYF with KEYFLD ?

OR do i need to change the KEY fields within the PF (DDS) to match the KEY
fields referenced by the OPNQRYF & then recompile the RPG ?


*RPG application and OPNQRYF key mismatches might produce*

*different results*



Existing RPG applications that position a file using *SETLL *or *SETGT
*with
*LOVAL or *HIVAL, where the file corresponds to an OPNQRYF native query,
might produce different results in v7r2 than in prior releases. This
difference will only occur in cases where the RPG application was compiled
with a file having a different key definition than what was specified on
the *OPNQRYF KEYFLD *parameter. This mismatch was typically caught at
application coding time, and corrected. However, certain mismatches can
appear to produce the results expected by the programmer, and so it was
not
previously discovered.



In v7r2, depending on the nature of the mismatch, the behavior may be
different. If this mismatch is discovered, the application should be
recompiled to ensure the key definitions match. Also, if *SETLL *or
*SETGT *with
*LOVAL or *HIVAL is used only to position to the top or bottom of a
collated result set, then consider using SETLL *START or *END, which does
not require keys generated by the compiler.

----
Regards,
Mohan Eashver
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD