Compare these two files, Primary key 1-10. If there is a change in the field 11 to 22, then the output file should have [Primary key, Field 11 to 22 from file 1, Field 11 to 22 from file 2]
Based on the value in cols 34 to 38, I am writing two files.
Here is the ICETOOL job I am using. It is working perfectly fine, except for 1 record. Somehow, there is one record which is sneaking in the output file. The record is 0000273902000000000273XXXX. This is EXACTLY the same in both the input files!! Hence should not be appearing in the output file.
Trying to find out if there is an unknown mistake in the code. Any suggestions would be of great help. I have written another job, (actually 2 jobs, one ICETOOL and another using the SPLICE operator) which is giving me the desired result. But I want to minimize the number of JOBS or STEPS and write an efficient job which will do it in fewer steps. That is what the code copied above is trying to do.
Observed that for record, 0000273902000000000273XXXX... , the output file has 0000273902000000000000000000000273ZZZA - Zeroes in col 11-22 (which is from infile1).
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Tue Oct 03, 2006 2:27 pm Post subject:
Quote:
I have written another job, (actually 2 jobs, one ICETOOL and another using the SPLICE operator) which is giving me the desired result. But I want to minimize the number of JOBS or STEPS and write an efficient job which will do it in fewer steps. That is what the code copied above is trying to do.
Huh? Why would you need one ICETOOL and another using the SPLICE operator? You can do multiple operations in one ICETOOL step (as you're doing in the job you show). And why do you assume that your ICETOOL job with four SORT operators is more efficient than an ICETOOL job with I assume two COPY operators and a SPLICE operator? If anything your job with the four SORT operators seems overly complicated.
If I was going to do this, I'd SPLICE the two records for each key together, do the compare on the single record, and output the needed fields. I could show you how to do that, but I'd rather not reinvent the wheel if you've already done it with the SPLICE job you're talking about. If you do want me to show you how to do it, tell me the RECFM and LRECL of each input file. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
But you said that "the output file should have [Primary key, Field 11 to 22 from file 1, Field 11 to 22 from file 2]", so that would give the 34 bytes I got rather than the 38 bytes you got. Did I misunderstand something? _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
No Frank. You got it all correct. I had split the output file into 2 different files based on the last 4 columns. I did not make a perfect problem statement when I first posted the question.
Thanks for the response and a wonderful solution. I am yet to try it out, shall do it first thing in the morning tomorrow morning.
Joined: 02 Dec 2002 Posts: 1618 Topics: 31 Location: San Jose
Posted: Wed Oct 04, 2006 4:02 pm Post subject:
Glad I could help. _________________ Frank Yaeger - DFSORT Development Team (IBM)
Specialties: JOINKEYS, FINDREP, WHEN=GROUP, ICETOOL, Symbols, Migration
DFSORT is on the Web at:
www.ibm.com/storage/dfsort
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum