Re: AW:Cycle equivalent of ITER?

I am assuming both files are keyed in the proper key sequence
Seems to me to be an ideal case to make the full-procedural file the secondary.
Specify L1 M1 on the match fields.
Say you use record id indicator 01 for primary and 02 for secondary then
01NMR can be used to process the primary.

Depending on how many records are in the full-procedural (secondary) file for each primary, performance should be ok.
Matching records is rarely used these days but I found it was very easy and saved a lot of coding for controlling the read logic and report output ,headings, totals etc..

Before SQL had Full Join I preferred to use Match-record logic when I needed to process 3 or more files with matching keys.

Today I would construct an SQL to give me just the unmatched Primary records and code a SQL fetch loop to process them one at a time.

fwiw
Frank



On 23/06/2022 3:44 am, James H. H. Lampert via RPG400-L wrote:

On 6/22/22 10:10 AM, k.fritz@xxxxxxxx wrote:

    Use a Goto and Tag op-code for that.

Thanks to all who responded. I'm actually more than a little bit surprised. And no, secondary files aren't involved; just one primary and one full-procedural.

As to what I'm doing, I'm deleting the primary file record and calling a web service, if a corresponding record in the full procedural file can't be found. And unfortunately, finding that corresponding record is not as simple as I'd like it to be.

--
JHHL