Re: Match field of file A out of sequence

["VIJI SETHURAMAN" <VIJI.SETHURAMAN@xxxxxxx>]

It does not matter how the records are sequenced in the input files.  What
matters is how they are read into the buffer and
compared for matching.

If you have an OPNQRY, which sequences the records in one way, and your file has
a different key sequence,
check how you read the records into the program.  Maybe, it is KEYED?  remove
the "K" and try again?

cheers,

viji
DFS group Ltd.
SFO





"Khouw Thiam Hok" <thiamhok@yahoo.com> on 08/18/2001 06:58:51 PM

Please respond to rpg400-l@midrange.com

To:   rpg400-l@midrange.com
cc:    (bcc: VIJI SETHURAMAN/US-SFO/USERS/DFSGL)

Subject:  Re: Match field of file A out of sequence



Hi Doug,
Actualy the primary and secondary  file are sorted properly by OPNQRY
statement. 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?
I should give more focus on my input DB and try to simulate input file (P &
S) using WRKQRY  again, on Monday ofcourse.
Hopefuly can find something there.
Thanks again,
Hok
----- Original Message -----
From: "Douglas Handy" <dhandy1@bellsouth.net>
To: <rpg400-l@midrange.com>
Sent: Saturday, August 18, 2001 12:12 PM
Subject: Re: Match field of file A out of sequence


> Hok,
>
> >The message is "match field of file xxxx out of sequence" .. Error
message can't
> >give any statement/line which is problem lies(*N) .  Has anyone met this
message ?
>
> It can't give a statement number because this error is being detected
during the
> automatic matching records logic processing and is therefore implicit
rather
> than at an explicit statement number.
>
> The error message will identify the file, xxxx in your message above.
This will
> either the primary file, or one of the secondary match files.  In mathing
> records processing, every match file must read the records in ascending
(or
> descending) sequence by the match field(s) for that file.
>
> That is, each match file will have one or more match fields identified by
M1,
> M2, etc  These are concatenated to create the value to compare against the
other
> file(s) with match field(s).  The match fields are combined starting at M9
and
> continuing through M1.
>
> Each such file has its respective match field(s) concatenated into a
compare
> value.  The file with the lowest value gets processed each cycle.
Matching
> values get processed for the primary file first, then secondary file(s) in
the
> order they appear in the F-specs.
>
> This process repeats giving you records in turn for whatever file had the
lowest
> value at that point in time.  That is the gist of matching records.
>
> But the only way for this process to correctly match all records in the
files is
> to have each respective file be in order by the match field(s).  In the
old days
> that was done by presorting the punch cards.  These days it is typically
done
> via an access path whether via logical file or OPNQRYF.
>
> So as each record is read from a given file, the match field(s) is
compared to
> the previous record from *that* file to make sure it is not lower than the
> previous value (or higher if using descending matches).  If this test
fails, the
> error message you got is issued.
>
> This process was *very* useful in the punch card days, where you'd have
one
> stack of cards with transactions, and another stack with the master file.
No
> disk drives.  Matching records made it a piece of cake to process the
> transaction batch.  Almost like magic it took so little code.  I digress.
>
> Get the filename from the error message.  Do a WRKJOB to display the open
data
> paths, and find out what record number is being processed.
>
> The usual cause is having a misplaced punch card in the input deck.  If
that is
> not it <g>, then check to see if the F-spec is processing the file by a
key or
> by arrival sequence.  If by key, ensure the key field(s) are the same as
the
> match field(s) -- sequenced as M9 to M1.  If by arrival sequence, check
the
> process which creates the input file as it apparently used to create it in
the
> correct arrival sequence but now has at least one record off.
>
> There is a lot of mystic surrounding matched records processing, like it
is some
> dark secret.  It is actually quite straightforward.  I'll admit I haven't
coded
> a new one in years, but it works now just like when I learned it in the
70's...
>
> Doug
>
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
> To post a message email: RPG400-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
> or email: RPG400-L-request@midrange.com


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@midrange.com
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l
or email: RPG400-L-request@midrange.com