Re: Matching Records

Luv ya, Booth, but you're wrong this time. Only one indicator from a Primary/Secondary file set can be on at a time. Somehow the compiler "knows" that there's a matching set in the two files. I started to say "pair" instead of set, but either file (though usually the secondary the way I code) may have multiple records that satisfy the match. For example an order header being matched against an order line file solely on order number. The line file will (hopefully) have 1-n matches against the header.


Say, anyone game for Look Ahead processing?


* Jerry C. Adams
*IBM System i Programmer/Analyst
B&W Wholesale Distributors, Inc.* *
voice
615.995.7024
fax
615.995.1201
email
jerry@xxxxxxxxxxxxxxx <mailto:jerry@xxxxxxxxxxxxxxx>



Booth Martin wrote:

hmmm... I don't read the manual well enough sometimes, but I believe that the MR indicator, and the file processing, is such that the next 02 is always there, and known. Otherwise there would be no way for the program to know which record to grab next. In other words, when MR is on, then 01 and 02 are also on. If there is one 01 record and 5 matching 02 records, then MR will stay on while all six records are processed. If MR is off then we know we have a widow or an orphan.

Then again I could be wrong as heck. :)



Joe Pluta wrote:

From: Booth Martin

Why not select?

select
when *INMR and FILE1DS = FILE2DS
* (do nothing)
when *INMR
write MR_Diffs
when *IN01
write NMR_01
when *IN02
write NMR_02
endsl

Isn't that about all of the choices that there are?

Close, except the comparison of non-key fields is only valid when both
records are read in, which only happens when *IN02 is on.

select
when *IN01 and not *INMR
write NMR_01
when not *INMR // *IN02 is implied
write NMR_02
when *IN02 and FILE1DS <> FILE2DS // *INMR is implied
write MR_Diffs
endsl

You ignore primary matching records entirely because you can't see the
secondary fields yet. You only process secondary records if the data fields
don't match.

Joe