Re: Record Number / RPG cycle

*IMHO* 

Whether AS/400 OR S/36, it has no bearing on the use of Matching 
Records. 

Sometimes its just the best way to do a process. I think us older 
'brownshoe' RPG programmers have a special fondness for MR that 
you newer guys just can't appreciate. 

I bet in the last 20 years there have only been 20 MR programs 
written in all the kingdom!



From:                   fkolmann@revlon.com.au
Date sent:              Fri, 18 Feb 2000 16:09:53 +1100
To:                     RPG400-L@midrange.com
Subject:                Re: Record Number / RPG cycle
Send reply to:          RPG400-L@midrange.com


"Bale, Dan" wrote:

> I never fully grasped the benefits of using matching records on the AS/400
> (maybe the S/36?)
>

OK I'll bite.   There are NO benefits to using MR.
With MR you must use Record ident. indicators and usually control break
indicators.

You will be sequentially reading 2 or more files at the same time.
One file is the Primary all others are Secondary.
The Sort keys on these files must be the same. eg Order Number. This will be 
your
Match field/s. The Secondary files will usually have more key fields eq Order
Number and Line Number, thats OK we will only use Order Number to do the
matching.

What MR does is merge all the records in all the files together, you  
effectively
are reading only ONE file,
that is sorted in Match Key sequence.
The system makes sure that you get the records in the correct order. The match
indicator tells you if the Primary has any matched Secondaries, or If a 
Secondary
has a matched Primary.

The first record you process could be from a Secondary file, this usually 
happens
when a Secondary record has no matched Primary record and the Key in the
Secondary is lower than the lowest Primary record.

Still in your Calcs you need to know which record has just been read. (record Id
indic)
You need to know if the record you are reading has keys that Match you primary.
(MR indicator)

You write your code in the following manner.  The sequence is NOT important as
the indicators will
take care that  the right bit of code is excuted at the right time.

This is assuming that your field names are unique in all you records, otherwise
it is advisable to rename them to make them unique.

In detail time cales.

Detail time ind.  control break  C   L1  (clear accumulators)

Process unmatched  Primary records eg  01NMR

Process matched Primary records  01 MR. At this time the data from the
Secondaries is not available.

Process  unmatched Secondary records  02NMR

Process matched Secondary.  02MR.  Now you have the data from the Primary and 
the
Secondary.


In Total Time calcs

Total time Control Breaks (calc on accumulators (eg. percent)  )

For brevity
I have omitted the  Heading Detail Total and Overflow output.
I have omitted Exception output and fetch Overflow.
Look ahead fields

Having said all that  I never did find MR very useful.  I always had a problem
with matching the lower order keys on secondary files. eg where an Order Header
MUST have Order Detail Record and each Order detail Record MUST have a Text
Record.





+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---