IBM Mainframe Forum

Hi,

Can anyone help me with JCL compare solution to compare a file like below.

File1 - VB file with max length of 27994 and key present in 101th position. There are records in this file where it don't have any data in 101th position because of VB file
File 2 - FB file with max length of 10 bytes and key starting in 1st position.

Now i wish to compare file1 and file2 and output needs to be produced with matching record

Thanks in advance for your help

Regards
Hari

JCL cannot do this; what tool do you wish to use?

Since the output requires matching records, it will be possible with SORT. Which one do you have? DFSORT or SyncSort?

We have dfsort in our system billy

OK, you need a simple JOINKEYS. Since you don't need the "short" records at all, you can ignore them in a JNFnCNTL dataset:



Is either input file in sorted order on the key?

These users thanked the author BillyBoyo for the post:

paramaha (Fri May 24, 2013 5:14 pm)

Billy, it worked perfectly as expected.. I just modified the key position alone..Can you explain the meaning of reformat parameters plz..

Yes, as well as my explanation, look in the manual, and experiment.

This REFORMAT is very simple. As there is no JOIN statement, you only have "matches" arriving in the "main task". Your File 2 is only a key. Therefore, we only need the data from File 1 in the REFORMAT. File 1 is of variable-length records, and you want variable-length output, so the REFORMAT needs to be variable-length. This is done with the F1:1,4 - it copies the RDW from the File 1, and after this DFSORT will ensure that it contains the length of the data in the first two bytes. You have variable-length data and the "5" on its own says "copy the data on F1 from position 5 to the end of the current record".

As there is no other processing in the main task (except the OPTION COPY), then the REFORMAT record, with the correct record-length, will simply be written to SORTOUT.

thanks Billy, for your timely help and guidance.

Hello,

I must be having a brain fade again. If one record has the "key value" and the other does not . . . . ?

...then they can never match, and since only matched records are wanted...

If these are different "record-types", it would be better to do the INCLUDE/OMIT by record-type. If there is a "third-or-moreth" record-type, you could get a "false hit", if the data happened to be that way.