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