|
View previous topic :: View next topic
|
| Author |
Message |
mistah kurtz
Active User
Joined: 28 Jan 2012
Posts: 316
Location: Room: TREE(3). Hilbert's Hotel
|
|
|
|
Hi,
Currently I have a job which is using comparex utility for file comparison.
| Code: |
//STEP01 EXEC PGM=COMPAREX
//SYSUT1 DD *
AAA
BBB
CCC
DDD
EEE
//SYSUT2 DD *
AAA
BBB
XXX
DDD
YYY
//SYSUT3 DD SYSOUT=*,DCB=(RECFM=FB,LRECL=3,BLKSIZE=0)
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
COPYDIFF
KEY=(1,3)
FIELD=(1,3)
MASK=(4,END)
//* |
The output from this job is:
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.
Thanks. |
|
| Back to top |
|
 |
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
| It is doing read-ahead. The options used should be visible or listed |
|
| Back to top |
|
|
mistah kurtz
Active User
Joined: 28 Jan 2012
Posts: 316
Location: Room: TREE(3). Hilbert's Hotel
|
|
|
|
This is what i'm getting in sysprint:
| Code: |
MAXDIFF=999999999999
PRINT=(MATCH,MISMATCH),MBRHDR=YES,HALT=COND,KILLRC=NO
WILDCARD=C'.',MODE=APPLICATIONS (ALL DISPLACEMENTS RELATIVE TO ONE)
SYNCHRONIZATION KEY(S):
KEY=(1,3,C,A)
DECIMAL,EBCDIC,CASE=MIXED,LINE=(32,HORIZONTAL),PAGE=58
DASH=C'-',PLUS=C'+'
IDENTITIES, DESENSITIZING, FIELDS, AND MASKS:
FIELD=(1,3,C) 1 FIELD=(1,3,C)
MASK=(4,END)
COPYDIFF
DATA,FORMAT=02
(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 |
|
|
| Back to top |
|
|
mistah kurtz
Active User
Joined: 28 Jan 2012
Posts: 316
Location: Room: TREE(3). Hilbert's Hotel
|
|
|
|
Hi Bill,
I'm using the following control card in Syncsort and it is working as expected (equivalent to Comparex).
| Code: |
OPTION COPY
JOINKEYS FILES=F1,FIELDS=(1,3,A),SORTED,NOSEQCK
JOINKEYS FILES=F2,FIELDS=(1,3,A),SORTED,NOSEQCK
JOIN UNPAIRED,F2,ONLY
|
Thanks! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8700
Location: Dubuque, Iowa, USA
|
|
|
|
| Quote: |
| I'm not able to understand how the DDD record is coming into output |
Your output explains why:
| Code: |
| KEY OUT OF SPECIFIED SEQUENCE - RECORD 4 ON FILE SYSUT2 |
|
|
| Back to top |
|
|
mistah kurtz
Active User
Joined: 28 Jan 2012
Posts: 316
Location: Room: TREE(3). Hilbert's Hotel
|
|
|
|
| Thanks Robert. I'm new to Comparex. Its extensively used at our shop, but I feel more comfortable with DFSORT/Syncsort, so I was searching for a sort based solution. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10888
Location: italy
|
|
|
|
| Quote: |
but I feel more comfortable with DFSORT/Syncsort, so I was searching for a sort based solution.
|
most organisations will not care about Your comfort
and will just TELL You to do things according to their common standards and practices |
|
| Back to top |
|
|
Akatsukami
Global Moderator
Joined: 03 Oct 2009
Posts: 1787
Location: Bloomington, IL
|
|
|
|
| enrico-sorichetti wrote: |
| Quote: |
but I feel more comfortable with DFSORT/Syncsort, so I was searching for a sort based solution.
|
most organisations will not care about Your comfort
and will just TELL You to do things according to their common standards and practices |
At least this is a refreshing change from "I have to write this program in RPG II because that is the REQUIREMENT1!!1'  |
|
| Back to top |
|
|
mistah kurtz
Active User
Joined: 28 Jan 2012
Posts: 316
Location: Room: TREE(3). Hilbert's Hotel
|
|
|
|
| Quote: |
| most organisations will not care about Your comfort |
Yes I understand that. But at our shop, we have COMPAREX as well as SYNCSORT and they are ok with either of it. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
Comparex is a comparison product. SyncSORT is a sorting product, which can do basic compares.
Be very aware that if you use unsorted data for a JOINKEYS you may get unexpected results. |
|
| Back to top |
|
|
sergeyken
Senior Member
Joined: 29 Apr 2008
Posts: 2145
Location: USA
|
|
|
|
| Bill Woodger wrote: |
| 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. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
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. |
|
| Back to top |
|
|
|
|
