Joined: 22 Jun 2007 Posts: 22 Location: Connecticut
I have a requirement to replace Comparex utility in a job step with SYNCSORT. The comparex did the following..
There are 2 input files with 252 LRECL & FB format.. Any records that are added this month, (not in file1 but in file2) will be added to output file3. Any records that are deleted this month, (in file1 but not in file2) will not, repeat not, be added to output file3. Any records that is changed this month (in file1 & also in file2) will be added to output file3 unless the only field to change is Data field in the record (POS. 200-207).
With comparex, Mask command has been used for that date field condition.
Now i need to implement the above logic with the help of any sort commands.. I tried with Joinkeys command.. Wud say worked out 50%.
Few records which i was expecting didn't come in the output file... And also order was not the same compared to old output file.(though im not that much worried about it right now)..
Can any of you let me know what is the correct sort command to be used in this place or how to solve this????
Joined: 22 Jun 2007 Posts: 22 Location: Connecticut
Hello,
Thanks for the PDF. But it didn't have example with regard to my requirement.. In my case, a field needs to be masked off before comparing. At the same time, it should be there in the output records.
hi
i have used superc in one step and compared 2 files and get the output in third file and in next step you can strip the prefixes D OR I using syncsort .you will find the example jcl in tso forum just search .probably it may work for ur case.still iam looking for other options like splice option of icetool .workin on it.
Joined: 22 Jun 2007 Posts: 22 Location: Connecticut
As an update, I tried with PGM=ICETOOL but i didn't get any matched records.. Im still working on it.. As Dick Quoted, PGM=ICETOOL did invoke syncsort.. i could see that in job output.
SYT000I SYNCTOOL RELEASE 1.5.1 - COPYRIGHT 2004 SYNCSORT INC.
SYT001I INITIAL PROCESSING MODE IS "STOP"
SYT002I "TOOLIN" INTERFACE BEING USED
* ADD '11' IDENTIFIER FOR FILE1 RECORDS.
COPY FROM(IN1) TO(T1) USING(CTL1)
SYT020I SYNCSORT CALLED WITH IDENTIFIER "0001"
SYT030I OPERATION COMPLETED WITH RETURN CODE 0
* ADD '22' IDENTIFIER FOR FILE2 RECORDS.
COPY FROM(IN2) TO(T1) USING(CTL2)
SYT020I SYNCSORT CALLED WITH IDENTIFIER "0002"
SYT030I OPERATION COMPLETED WITH RETURN CODE 0
In the above example, the bolded data fields are the fields to be masked acc to my requirement. As i was trying with syncsort - Joinkeys, i skipped giving this field pos (200-207 in my case) in the joinkey command...
So if you imagine masking that field in both the files, the result would be duplicate records in file 2 as against the record in file1.
Hence my syncsort considers all the 5 records in file 2 as pair of the single record in file 1.. and doesnot write anything into the output file..
Whereas, the output that im expecting is (plainly what comparex does) - only 1 record in file2 should be considered as pair against file1 and rest 4 records from file2 should be written into output file...
Can anybody now help me for this situation.. Apart from this, i was able to get the solution......
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Hello,
Please post all of your jcl and control statements (using the "Code" tabe at the top of the reply panel). Also, please post the sysout information from the execution.
I'm probably mis-understanding something, but it appears to me that either all 5 recordds in file2 match or 2 of the records in file2 match, but i am confused as to why only 1 should "match". If there is to be only a "single match" which should it be?
Referring to what comparex does will probably not help much here as only a few posters seem to have the product installed. . .
WER164B 5,372K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 1,024,008 BYTES USED
WER146B 20K BYTES OF EMERGENCY SPACE ALLOCATED
WER481I JOINKEYS REFORMAT RECORD LENGTH= 252, TYPE = F
WER110I SORTOF03 : RECFM=FB ; LRECL= 252; BLKSIZE= 27972
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER405I SORTOF03 : DATA RECORDS OUT 0; TOTAL RECORDS OUT 0
WER416B OUTFIL WAS USED FOR SORTOF03
WER054I RCD IN 0, OUT 0
WER072I NOEQUALS IN EFFECT
WER169I RELEASE 1.2 BATCH 0427 TPF LEVEL 1.1
WER482I JNF1 STATISTICS
WER483B 2,548K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER483B 0 BYTES RESERVE REQUESTED, 1,772K BYTES USED
WER108I SORTJNF1 : RECFM=FB ; LRECL= 252; BLKSIZE= 27972
WER483B 1,516K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER483B 0 BYTES RESERVE REQUESTED, 1,516K BYTES USED
WER483B G=118
SORTJNF1 : RCD IN= 1,OMITTED= 0,PAIRED= 1,UNPAIRED= 0
SORTJNF1 : EXCP'S=1,UNIT=3390,DEV=39A8,CHP=(9FA7AFB0B2B6,1),VOL=SMS273
TOTAL OF 1 EXCP'S ISSUED FOR SORTING
FILESIZE 252 BYTES
JNF2 STATISTICS
2,548K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
0 BYTES RESERVE REQUESTED, 1,772K BYTES USED
SORTJNF2 : RECFM=FB ; LRECL= 252; BLKSIZE= 27972
1,516K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
0 BYTES RESERVE REQUESTED, 1,516K BYTES USED
G=118
SORTJNF2 : RCD IN= 5,OMITTED= 0,PAIRED= 5,UNPAIRED= 0
SORTJNF2 : EXCP'S=1,UNIT=3390,DEV=3BD7,CHP=(9FA7AFB0B2B6,2),VOL=SMS220
TOTAL OF 1 EXCP'S ISSUED FOR SORTING
FILESIZE 1,260 BYTES
END SYNCSORT - N482A8J,STEP12B,,DIAG=8E00,414E,A28C,00EE,C662,68C2,A6C
DIAG1=EE00,704A,C29C,A4DF,A763,48C3,86C8,8D60
DIAG2=A800,724C,809C,A05D,E163,4CC3,02C8,8F60
As you can see, the output file is empty. Dick, with regard to your question, im also struck by the fact why only 1 record should be assumed as match. But tht's the way i have been asked to come up with the result.. ... the first pair that the file1 record encounters in file 2 should be considered as match.. and the rest to be written into the output file..
Let me know if i have missed quoting anything.. Thanks.... I tried this concept with ICETOOL too.. but same result..
if u notice, the 2nd record from file2 was considered match against file1 and the rest were deducted as new records and written into the output file.. (no clue as to why it didn't consider the first record as a pair which i was expecting)
Below given is the filemaster logic for this problem...
As one of the members quoted in this thread, both superc & filemaster would return us with the summary details, from which we have to strip out required result.
im trying out various other duplicate scenarios that exists in my case and will keep you people updated with my results..
Thanks a lot for everybody's help on this.. Kindly do update me if you people feel there is any other way we can approach this problem..
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
Helllo,
It may be helpful to add a few more records to file 1 that are of completely "new" content (rather than more like the ones already in file 2) and corresponding new records in file 2. If there are multiple "cases" the result may help understand what exactly is happening and why the second record was the one chosen in your test.
Joined: 22 Jun 2007 Posts: 22 Location: Connecticut
Hi Dick,
You were right.. Today i digged into the thread of this job and after a prolonged discussion, came to know that the current process of filtering the duplicates in the previous step isn't working at all. Due to that, we had this weird concept of "match one , rest into file". Now the duplicate issue will be sorted out and hopefully Syncsort should work out well.
Thanks all for your help.. Will keep posting queries regularly..
... the first pair that the file1 record encounters in file 2 should be considered as match.. and the rest to be written into the output file..
which i was expecting)
