Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
This is worth fully understanding, rather than just poking it into production cos it works.
It took me some time to get it, so here's what I came to. Hope I got it all :-)
Don't be confused by all the 81s. There are two different sets of them.
The two JNFnCNTL files add a sequence number to each record, but the sequence number is "off by one" between the two files. The main file (F1) has the larger sequence number (default start for sequence number is one), and that is important.
The JOINKEYS matches on the sequence number.
After that point, forget the sequence number, it is irrelevant.
The REFORMAT takes the whole F1 record and the first two bytes of the F2 record, the key.
These two bytes on the REFORMAT record start at position 81.
Now the single REFORMAT record contains "current" record and "next" record key. When "current" and "next" keys are different, the "current" is the last of that key.
Everything goes smoothly until the last record on F1, which doesn't match to a sequence number on F2. No problem, that is what the UNPAIRED,F1 is for. The ? match marker will have a value of "1", which will indicate end of group, and indeed end-of-file if that is required.
Thanks Kolusu, that is useful, not only in itself, but also for thinking about how to do other things.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
Partly so that interested parties get to see the edits, I'll add that the technique has also been used to keep running-totals for records by key and a somewhat esoteric "delete duplicates without sorting" (which can be done with ICETOOL anyway).
For anything which requires the presence of data/keys at the same time from consecutive records, this technique can be considered.
.jpg)
