Hi All,
I am trying to understand how merge works using DFSORT. I have taken an example for that and tried executing the sort step. I have landed with below results.
Input file details:
SORTIN01 - LREC(80) and RECFM(FB)
Dataset: TDMS.TAPAS.TEST1
0005 VFRD 12344 MAN THIS IS
0009 UTUY OP664 FIRST FILE
0909 VFRD HHH44 HEY MAN HI
0934 AJHJ IOIOO MAKK KOK SO
1234 ABCD HELLO HOW ARE YOU
1234 OOPD PLOLO OIOIOIO YOU
1415 TRRY 099LO LLKLLRE YOU
4565 NVHD 12344 HEY MAN HI
4589 DFAD 10104 HEY MAN HI
5476 MNMN H099O KAKAOIIOYOU
5565 KJKJ 0990B HEY MAN HI
7787 IQPO BOSSO SO YOU ARE
______________________________________________
SORTIN02 - LREC(80) and RECFM(FB)
Dataset: TDMS.TAPAS.TEST2
0009 UTUY OP664 KOKKKON HI
0934 AJHJ IOIOO MAKK KOK SO
1234 ABCD HELLO SECOND FILE
1234 OOPD PLOLO OIOIOIO YOU
4565 NVHD 12344 HEY MAN HI
4565 VFRD 12344 MAN THIS IS
4589 DFAD 10104 HEY MAN HI
5476 MNMN H099O KAKAOIIOYOU
5565 KJKJ 0990B HEY MAN HI
8885 TRRY 099LO LLKLLRE YOU
8885 VFRD HHH44 HEY MAN HI
9894 IQPO BOSSO SO YOU ARE
0005 VFRD 12344 MAN THIS IS
0009 UTUY OP664 FIRST FILE <---- Query 1
0009 UTUY OP664 KOKKKON HI <----- Query 1
0909 VFRD HHH44 HEY MAN HI
0934 AJHJ IOIOO MAKK KOK SO
0934 AJHJ IOIOO MAKK KOK SO
1234 ABCD HELLO SECOND FILE <-----Query 2
1234 ABCD HELLO HOW ARE YOU <-----Query 2
1234 OOPD PLOLO OIOIOIO YOU
1234 OOPD PLOLO OIOIOIO YOU
1415 TRRY 099LO LLKLLRE YOU
4565 NVHD 12344 HEY MAN HI
4565 NVHD 12344 HEY MAN HI
4565 VFRD 12344 MAN THIS IS
4589 DFAD 10104 HEY MAN HI
4589 DFAD 10104 HEY MAN HI
5476 MNMN H099O KAKAOIIOYOU
5476 MNMN H099O KAKAOIIOYOU
5565 KJKJ 0990B HEY MAN HI
5565 KJKJ 0990B HEY MAN HI
7787 IQPO BOSSO SO YOU ARE
8885 TRRY 099LO LLKLLRE YOU
8885 VFRD HHH44 HEY MAN HI
9894 IQPO BOSSO SO YOU ARE
As per the output above, for the records where the merge key is same in both first file and the second file, record tagged with Query 1 has the record from the first file coming first and then the record from the second file. But this is oppposite when it comes to record tagged with Query 2. Please explain me why is this difference. As per my understanding of merge, when the merge keys match then record from the first file will be written first and the second file record. Please correct me if I am wrong.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
As per my understanding of merge, when the merge keys match then record from the first file will be written first and the second file record. Please correct me if I am wrong.
That is only true if EQUALS is in effect for the run (if NOEQUALS is in effect, then records with duplicate keys can be written in any order). Since you didn't show the //SYSOUT messages, I can't tell if EQUALS or NOEQUALS is in effect (but I suspect it's NOEQUALS). To be sure that EQUALS is in effect, you can add this to SYSIN:
Hi Frank,
Thanks for your reply. Yes you are correct, I checked in SYSOUT and found that option UNEQUALS is in effect. After giving the OPTION EQUALS, I got the desired result.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
MERGE FIELDS=(6,4,CH,A,1,4,CH,A)
merge works even though primary field not in any sequence?
It's not clear what you're asking.
In order for that control statement to work, each input file (SORTINxx) must already be sorted by 6,4,CH,A,1,4,CH,A. Otherwise, you'll get an out of sequence error.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Oh, I see what you're saying. I didn't really look at the poster's data since he said it merged ok. With the data as shown and that MERGE statement, he would get an ICE068A out of sequence error. With the following MERGE statement, it would work ok:
Code:
MERGE FIELDS=(1,4,CH,A,6,4,CH,A)
So you're right that something he's telling us "does not compute".
Hi All,
Yes we need to have the merge fields as given by Frank. Infact I had executed the step with the same merge statement, But as I was playing around with the sort and trying to understand how it processes I pasted the wrong JCL. Sorry for the confusion.