Re: Match field of file A out of sequence

Hok,

>Actualy the primary and secondary  file are sorted properly by OPNQRY
>statement.

With all due respect, the message suggests otherwise.  One possibility here is
that the OPNQRYF is not being applied to the open data path used by the program
-- for instance if it is scoped in a different activation group.

By any chance did this program recently get converted to RPG IV?  If it is in
RPG IV, what activation group is the program in?  How is the OVRDBF declared?

It is not uncommon for people to "lose" an OPNQRYF effect if they convert to RPG
IV but don't understand scoping rules.

>And the message is detected by primary file. From dump report
>it's hit at RRN nnn. From this record (RRN nnn)  I try query the secondary
>file, but not such record (match) are found. Could it be the problem?

The secondary file is of no consequence here.  Forget about it for right now, as
it is not part of the problem.  The message is saying the *primary* file just
encountered a record where the match field(s) of the record read are out of
sequence compared to the previous *primary* record.  If the sort is in ascending
order, then the primary record just read has a lower match value than the record
before it.

Since you are using OPNQRYF, it is not a matter of just looking at the PF
records surrounding the RRN in question to see what values they have.  If you
were to run your program under debug with a breakpoint on the first calc line
then examine the RRN of the primary file each cycle, you could watch the order
in which OPNQRYF has sorted the access path.

But you may find that the RRNs are 1, 2, 3, ... with some numbers repeated on
the cycles where a secondary record is being processed.  If your RRNs are
incrementing, either your PF was already partially in sequence or the OPNQRYF
did not take effect.

If you are using RPG IV, you may want to try changing the override to:

  OVRDBF FILE(xxx) SHARE(*YES) OVRSCOPE(*JOB) ...

and see what happens.

>I should give more focus on my input DB and try to simulate input file (P &
>S) using WRKQRY  again, on Monday ofcourse.

Don't bother with the secondary file.  Neither is the order shown by a Query
going to prove whether your OPNQRYF is truly in effect.

Check your activation group and override scope if using ILE.  Make sure the file
has an override with share *YES.  Make sure the primary file has a K for keyed
access.

If all these things seem correct, then put the program in debug and watch the
RRNs of the primary file reads.  When your error occurs, check the RRN of that
record and the RRN of the primary record last processed.  Compare the match
field(s) from those records, with M9 having a higher priority than M1.

Doug