IBM Mainframe Forum

Hello,

SUPERC tool showed timeout error!

Suggest you run this in batch. If the job abends with a timeout, ask your support people which class you should use for a job that exceeds the allowed time for the class you are using. Your organization may permit changing the TIME parameter on the JOB statement to allow more.

thermalchu,

The maximum length of a field you can sort is 4092 for character data. So you cannot use SORT to compare 7000 bytes of data. You need to write a program for the comparison.

check this link which shows the Control Field Formats and Lengths allowed

//STEP1 EXEC PGM=SORT
//SYSOUT DD SYSOUT=*
//SORTJNF1 DD DSN=PXXXX.SORT1.PS,
// DISP=SHR
//SORTJNF2 DD DSN=PXXXX.SORT2.PS,
// DISP=SHR
//SORTOUT DD DSN=PXXXX.MISMATCH.PS,
// DISP=SHR
//SYSIN DD *
JOINKEYS FILES=F1,FIELDS=(1,7000,A)
JOINKEYS FILES=F2,FIELDS=(1,7000,A)
JOIN UNPAIRED,F2,ONLY
REFORMAT FIELDS=(F2:1,7000)
OPTION COPY
/*

It is showing ths error:
ICE407A 0 JOINKEYS STATEMENT HAD TOTAL KEY LENGTH GREATER THAN 4080 BYTES

Did you read Kolusu's post? Right above your last?

Because your record is 7000 bytes, you are running into limits. DFSORT is not a file-comparison product.

Are you expecting your files to match? Is there something you regard as a "key"?

Did you try the suggestion about SUPERC?

SUPERC, I tried as batch program. It took almost 6 hours to complete and then abended. SUPERC is time consuming. There is a 9 digit key starting from 12th position.

OK, odd, but what about my other questions?

Plus, are there duplicates on either file on the basis of the key?

About how many records are we talking of?

There are 4million records in both files. I sorted them using ICEMAN and Dynamic allocation. Almost all records will be matching. We have to check whether there is some difference in them. The records are like this:
CBF 100002345 JFGHHGJD GJDFHD DGGJH.......(7000 BYTES)
CBF 100002367 JAFSAGJD WETEY EYERUUDF.....(7000 BYTES)
The ID which starts from 12th position will be same for both files since sorted. We have to check whether there is any change is remaining record.

Have you started on your 2 file match program yet? You could have done it by now even working on it part-time.

very dirty, but quick enough

why not run two compares
1) key and the first 3500 bytes
2) key and second 3500 bytes

Will it be possible? Because only first part contains the KEY.