× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.