IBM Mainframe Forum

Follow on:

I've been assuming that you have a task which can be achieved (reasonably).

To stop assuming that:

1. The files have to be in the same "order", even though the files are not sequenced. Record two (match) on file two must appear after Record one (match) and before Record three (match). This must, similarly, but true for all the matches.
2. All the data on file one must match with data on file two.
3. Duplicates can be handled, but have to be coded-for with an exact knowledge of the particular possibilities.

So, if you can describe your data for us, what the match is done on and show us some sample data and confirm that everything meets the above criteria, then we can assist.

Hello,

Why does someone believe you need to write code to "match" 2 files with no common key on which the files can be sorted/compared?

If you only want to see if the files/records are the same or different, suggest you consider the utility superc.

I've used it for analysing text files. Extract paragraphs which contain particular words. Select from those paragraphs the words in particular combinations/amounts. Go back to the source file to get the article titles using the paragraph. Decide again which to take depending on the relevance of the title. Go back to the text file to pull the whole article using the title.

To do the match, take the two-file merge and turn it "sideways" as I like to call it. It is the same thing, just with a driver file, and read-until-match on one file only (rather than file with lowest key).

I guess any data which does not have a natural key and from which the final driver file has been originally sourced.