× 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.


  • Subject: Re: Record Number / RPG cycle
  • From: "Jim" <jcannon@xxxxxxxxxxx>
  • Date: Mon, 21 Feb 2000 09:21:35 -0700

*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
+---


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.