Generic File Comparison Utility

The program can be run on any two files with identical file layouts. For the file, Key fields and Data fields are specified. The Key fields do not need to correspond with the file's "natural" key, but the combination of key fields must result in a unique key. At least one field of each type (Key and Data) must be specified. The program sorts the files based upon the specified key fields, and the performs a merge sort (aka Matching Records). One of four states is possible after each read:

The first key is less than the second key (Unmatched records)

The second key is less than the first key (Unmatched records)

The keys are equal, but there are differences in the specified data fields (Unmatched records)

The keys are equal and the specified data fields are different (Matched records)

The table that drives all this is CP1000F. Following is an example when loaded for JDEdwards UDC tables:

The image I had in mind while writing this was of someone sitting with two file dumps in front of her (comparing
them line by line); one on the left (L) and one on the right (R). All we are doing is automating the comparison.
The significance of the report is as follows (by line):

Record 82/GR/DJEKYLL exists in CLTCOMDEV, but not CLTCOM

Record 82/GR/FJUSTICE exists in CLTCOM, but not CLTCOMDEV

Record 83/08/CA1 exists in both files, but with differing data

A couple of notes:

Key field column headings use equal ("=") for underlines

Data field column headings use minus ("-") for underlines

Column widths are the greater of either the field length or the description (from CP1000F) length. This gives us
the ability to have descriptions wider than field (I don't like one character column descriptions).

If the description length is greater than the field length, the field will be centered.

In addition:

This does not work at all if there is a negative numeric key. Now, I don't think files with numeric keys shoul
allow negative values, but this is still a bug.

Extra logic exists when a field takes more bytes on the page than in the file (e.g. binary, packed). The logic for
packed fields serves as an example for anyone wanting to implement binary, etc.

It would be really slick to, if all the selected data fields are numeric, group across non-unique key fields,
and the perform the comparison on the subtotals. Again, left as an exercise (but if you do it, send me the source and
I'll incorporate it here.).

The following link takes you to the source code, written in beautiful /free ILE/RPG. Both the source and the compiled
objects are distributed under a create commons license.

Right-click on the following link to download a save file (saved to V5R1) containing the Utility. Create an empty save file
on the target machine, ftp the downloaded file up to the save file, and display the save file. You should see something similar
to the following: