Re: Matching Records - End Product

Murphy, Mark wrote:

7. RE: Matching Records - End Product (Murphy, Mark)

These are both very nice, but they won't work unless the last record in both files is a matching
record. So you have to add some complexity to prevent an infinite loop in all but one circumstance.

/free
read file1;
read file2;
dow (not %eof(file1) or not %eof(file2));
select;
when old.key = new.key;
update file1; //matched records logic...
read file1;
read file2;

What immediately bothers me in the examples is the way the EQUAL condition reads /both/ files -- you mention this at the end of your post. What happens if file2 has multiples of the same key? (I.e., file1 is OrderHeader and file2 is OrderDetail with many line items.) The file1 has now been positioned to the next record which is now a mismatch against file2. Unless it's file1 that has the multiples...

MR wouldn't miss such a condition and would properly read and present _only_ file 2 _or_ file1 depending.

Are we seeing examples of "production" logic? Hmmm...

Meanwhile, I wrote a program a couple weeks ago --

FCpyBk ipe f 132 disk
FCopyBk o e disk rename( COPYBK:COPYBKR )
ICpyBk aa 01 19nc/ 23 c:
I 27 36 SrcMbr
ICpyBk aa 02 19 c/ 23nc:
I 4 63 CpyMbr
ICpyBk aa 03
C/free
if ( *in02 ) ;
write CopyBkR ;
endif ;
/end-free

I ran FNDSTRPDM over a big bunch of source files in multiple libraries to get a picture of where all the /COPY directive was being used. The resulting 'report' was great for looking at, but didn't lend itself to any automation of what I wanted to accomplish. Source member names were on lines by themselves. The source lines with /COPY were individual items on subsequent lines. All the data I wanted were in that report, but how to turn it into the information I wanted...?

Turns out that a simple CPYSPLF followed by some SQL DELETEs gave me a nice sequential file with just lines for member and source lines. Perfect for record-identifying indicators and a trivial RPG program. The output was a table with SrcMbr in the first column and the full /COPY directive in the second column. The differences between the report lines was what defined the record IDs.

From there, I very quickly had a snap-shot database that cross-referenced every copy-member with every source-member that used each of them.

At each point along the way, a "tool" suggested itself. Was each the "right tool" for the job? I don't know. The total time programming was about as small as I could ever get given my starting point. The total source lines aren't much more than double the size of the RPG program. And there aren't many chances for logic errors. (Though it doesn't adapt well to future changes in FNDSTRPDM output format and other pitfalls, so it will never be "production" code.)

Tom Liotta