I'm not able to understand how the DDD record is coming into output. I want to convert it to Syncsort. The version of Syncsort taht we have supports JOIN statements. Could you please help me to understand the comparex functionality.
PS: I have raised a request for the Comparex Manual, meanwhile I thought I will post here.
PPS: By mistake, I posted it in JCL section. Could you please move it into Syncsort section.
Joined: 28 Jan 2012 Posts: 287 Location: Room: TREE(3). Hilbert's Hotel
This is what i'm getting in sysprint:
WILDCARD=C'.',MODE=APPLICATIONS (ALL DISPLACEMENTS RELATIVE TO ONE)
IDENTITIES, DESENSITIZING, FIELDS, AND MASKS:
FIELD=(1,3,C) 1 FIELD=(1,3,C)
(FORMAT EXPLANATION: FULL SYSUT1 FOLLOWED BY DIFFERING LINES OF SYSUT2)
KEY SYNCHRONIZATION MISMATCH - RECORD 3 ON FILE SYSUT1
KEY SYNCHRONIZATION MISMATCH - RECORD 4 ON FILE SYSUT1
KEY SYNCHRONIZATION MISMATCH - RECORD 5 ON FILE SYSUT1
END OF DATA ON FILE SYSUT1
KEY SYNCHRONIZATION MISMATCH - RECORD 3 ON FILE SYSUT2
KEY OUT OF SPECIFIED SEQUENCE - RECORD 4 ON FILE SYSUT2
KEY SYNCHRONIZATION MISMATCH - RECORD 4 ON FILE SYSUT2
KEY SYNCHRONIZATION MISMATCH - RECORD 5 ON FILE SYSUT2
END OF DATA ON FILE SYSUT2
RECORDS PROCESSED: SYSUT1(5)/SYSUT2(5)/SYSUT3(3),DIFFERENCES(0,3,3)
EXPLANATION - 0 RECORDS DIFFER THAT SYNCHRONIZED TOGETHER
3 RECORDS WERE CONSIDERED INSERTED ON SYSUT1
3 RECORDS WERE CONSIDERED INSERTED ON SYSUT2
Be very aware that if you use unsorted data for a JOINKEYS you may get unexpected results.
When using surely unsorted input file just do not use SORTED option in your JOINKEYS statement.
If you expect the input file must be sorted, then use SORTED option to improve performance, but don't use NOSEQCK. In case the input key order is wrong you'll get an error message. NOSEQCK bypasses verification of input key sequence, and it MAY give unpredictable results without notification.
The performance improvement provided by NOSEQCK is miserable; there is no need to use it, ever.
Obviously if the data is known to be in sequence it is entirely appropriate to use NOSEQCK. For instance, if you build the keys for JOINKEYS in the JNFnCNTL files in a known sequence, then sequence-checking is pointless. If the data has been through a SORT, the sequence checking is pointless. If the sequence has been checked already and the file has not been updated, the sequence checking is pointless.
Obviously if you have bad systems when data which should be in sequence is not, then sequence-checking is a good way to establish that, but do it at the time the file is being updated (the time the out-of-sequenceness is being established) not just for the heck of it when you happen to be using JOINKEYS.