Re: IBM's memo about OPNQRYF n v7r2

[Mohan Eashver <mohankva@xxxxxxxxx>]

Here is a link to the IBM's memo.that i referenced..
https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzaq9/rzaq9osDBRPGOpnQryF.htm


----
Regards,
Mohan Eashver



On Fri, Aug 30, 2019 at 1:25 PM Mohan Eashver <mohankva@xxxxxxxxx> wrote:

> > Hi All,
> >
> > I like some help in understanding what IBM's memo implies. I have
> > included the memo at the bottom of this email.
> >
> > Would you be able to tell if IBM intends this memo only if RPG is using
> > SETGT or SETLL as it states literally on the memo.
> >
> > Or does the problem extend to all File positioning operations including
> > CHAIN/READE/READPE.
> >
> >
> > *IBM's memo about 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