Joined: 14 Mar 2007 Posts: 8797 Location: Welsh Wales
Warning: Do NOT use concatenation with referback as shown in this example. Use one MOD data set as shown in Kolusu's example. See my post below for an explanation.
Frank.
I've had a little play and this is what appears to give the correct results, or pretty near
As for your previous comment about WITHALL, try the code with and without that parameter and spot the difference.
A quick one that maybe Frank / Kolusu can help me to understand ....... I vaguely recalled a similar problem a long time back, and so I reversed the order of the two files concatenated as input to the splice, T2 before T1, and then the results started getting better. I can only assume that the order that the files are read is of some importance where the file without duplicate records was read in first.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
neelima.sinha,
The following DFSORT/ICETOOL Job will give you the desired results. The basic idea is to tag the key from unique key file at the end of every record in the duplicate file and compare the contents at the end with the key
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
A quick one that maybe Frank / Kolusu can help me to understand ....... I vaguely recalled a similar problem a long time back, and so I reversed the order of the two files concatenated as input to the splice, T2 before T1, and then the results started getting better. I can only assume that the order that the files are read is of some importance where the file without duplicate records was read in first.
Expat,
Please, please don't show examples using concatenation with referback! As I've said many times in this Forum, there's a system restriction that can result in loss of data when you do that. Use one MOD data set as in Kolusu's example above, rather than concatenated data sets with referback as in the example you show. All of the examples in the current DFSORT books and all of the examples Kolusu and I show avoid concatenation with referback.
To answer your question, yes the order of the records is very important. The first record is the base record. The second record and subsequent records are the overlay records. Which record you use as the base record makes a huge difference. If you don't understand why that is, please go back and read the SPLICE documentation paying attention to the descriptions of the base and overlay records.
the solution offered by expat Global Moderator solves problem to some extent but I am getting output only records with key 03000, but 02329 is getting lost.... I need all of them.
I have one small doubt. Does the WITH parameter affects any processing in selection of records. Because i tried the SKOLUSU code with changing
the WITH parameter from WITH(01,80) to WITH(02,80). Now i am getting empty output file.
Still now i beleived that only ON fields are used to determine if records match. But WITH field affects the selection process.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
karthikr44 wrote:
I have one small doubt. Does the WITH parameter affects any processing in selection of records. Because i tried the SKOLUSU code with changing
the WITH parameter from WITH(01,80) to WITH(02,80). Now i am getting empty output file.
karthikr44,
yes it does. You have changed the position of the field on the WITH but kept the length to spliced as 80. This pushes the key from file2 to be in 82 position instead of 81st position. The Include condition on the output file is checking if the first 5 bytes match the key at 81st position. Since you changed the position by 1 byte, the 81st byte is now a space and hence none of the records match.
