This is a part of the JCl being used to obtain a the first temporary dataset for splicing.
I want to confirm out whether the following mentioned steps are the exact manner in which DFSORT would produce the o/p. I have run the step and getting the correct o/p but would like to finalise it wont be failing in any condition
Functioning details
1) The include condition will be executed first and all the i/p records in IN1 satisfying the criteria will go to temp dataset.
2) The outrec step will executed next and only the mentioned fields will be populated.
3) The sorting will take place next and since I'm using first, only the first duplicate record is being selected and finally written to the T1.
I feel the Sum fields= None is not required in this case but added it for extra check.The actual requirement is to get only the first duplicate record.
3) The sorting will take place next and since I'm using first, only the first duplicate record is being selected and finally written to the T1.
To confirm what you want exactly, check these definition's:
Quote:
FIRST - keep only the first record for each value (that is, records with non-duplicate values, and the first record for duplicate values)
FIRSTDUP - only keep the first record for duplicate values
Frank
I have an doubt on the order of processing that you have mentioned,
I felt like SUM FIELDS=NONE is done before the FIRST.
Because when we mention FIRSTDUP in the place of FIRST , i did not not get any records in the o/p, that is SUM fields=none is removing the duplicates and because of this FIRSTDUP is not able to extract any record to the o/p.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Technically, you're right. There's a lot of interaction between ICETOOL and DFSORT, but the actual "FIRST" processing is done with an E35 which is processed after SUM. (I've been sick all week and not thinking too clearly at times.)
But the main point here is that SUM should NOT be used with SELECT since it either isn't needed or can interfere with SELECT's processing.
