Joined: 22 May 2009 Posts: 160 Location: Bangalore
I have a requirement where in two files have to be compared and if both the files are byte byte same then SET a RC code = 8.and if not then the third file is generated.
I have tried using the SORT and ICETOOL but when compared the the MAXCC is always set to ZERO.
Should there be a condition COND=(0,LT, SEt RC=8)
can you please help me on this to how can i be able to check the condition.
Is that the Third file be checked for the blanks and then set a MAXCC = 8. Please help me on this.
Joined: 22 May 2009 Posts: 160 Location: Bangalore
I have run the Job and below are the parameters
OPTION COPY 0009130
WER276B SYSDIAG= 285342, 1631991, 1631991, 3521025
WER164B 7,408K BYTES OF VIRTUAL STORAGE AVAILABLE, MAX REQUESTED,
WER164B 0 BYTES RESERVE REQUESTED, 2,288K BYTES USED
WER146B 20K BYTES OF EMERGENCY SPACE ALLOCATED
WER108I SORTIN : RECFM=FB ; LRECL= 250; BLKSIZE= 27750
WER073I SORTIN : DSNAME=<File1>
WER110I SORTOUT : RECFM=FB ; LRECL= 250; BLKSIZE= 27750
WER074I SORTOUT : DSNAME=NULLFILE
WER410B 5,868K BYTES OF VIRTUAL STORAGE AVAILABLE ABOVE THE 16MEG LINE,
WER410B 0 BYTES RESERVE REQUESTED, 2,164K BYTES USED
WER211B SYNCSMF CALLED BY SYNCSORT; RC=0000
WER416B SORTIN : EXCP'S=1,UNIT=3390,DEV=D0DB,CHP=(01050D12161F22,1),VOL=FPM0
WER416B BSAM WAS USED FOR SORTOUT
WER054I RCD IN 34, OUT 34
I need when both same files are compared the job should abend else it should run fine. currently even if both the files are same the job is running with MAXCC=0 but i need to modulate to run with maxcc=8 when both files compared are same.
Can you include the bit from the sysout which tells us which version of SyncSort you have?
You're going to be better with JOINKEYS instead of SPLICE.
If you use OUTFIL OMIT for the F1 part of the REFORMAT equal to the F2 then if the files are identical, you'll have no output records. There is an option to set a return-code for no output from OUTFIL. Set your SORTOUT to DD DUMMY, as all you are interested in is the RC.
When i Used thabove JOINKEYS the F3 File is always filled with values.
Say in scenario Where Files F1 is compared to F1 then still in the O/P I get the records of F1.
Instead my scenario here is :
1. When Two identical files F1 and F2 are compared then the MAXCC should be set = 8.
2. When F1 and F2 different then The records in F1 which are not in F2 are to be copied to F3.
But the above JOINKEYS are not serving my purpose.
The "third file" is still a total mystery to me :-)
With the latest set of cards, if the files are the same byte-for-byte, there will be no data on SORTOUT. If not, all the unmatched F1 and F2 will be on SORTOUT.
There does seem to be a mention of a third file, but nothing clear as to what should be on it. If it is the unpaired F1s, then yes, the INCLUDE/OMIT has to go back to OUTFIL and another OUTFIL would be needed for the required data, which would be 251,250,CH,NE,C' '
SyncSort can give you 0, 4 or 16 for an "empty" file, either for SORTOUT (NULLOUT) or OUTFIL (NULLOFL).
If you have an up-to-date SyncSort, information which you still haven't supplied to us, you can set the same range for a file which contains data.
If you have the up-to-date SyncSort, you will be able to do it in one step - but your non-Zero RC can only be either 4 or 16. If you are "desperate" for an 8, you could do the IDCAMS on the 4 from the SORT, which then sets 8.
Without the up-to-date version, I think you'd have a problem where there are unmatched records on F2 and no records on F1. Your byte-for-byte match should obviously fail, but you'd get the NULLOFL for the unmatched F1 output, which would give the the "wrong" RC for the step.
Yes, if you're going to ignore questions and suggestions, you can make your topic wander off into other avenues: just bear in mind that people will be less likely to reply given the way things have gone so far on this one.
OK, you may be in luck. Check your documentation for NOTMTOFL.
This will allow you to set the RC (not to 8) if the specified OUTFIL contains data.
You have your byte-for-byte match. To get a full match, you have no unpaired records.
If you have differences, you have:
Differences are "new" records, only on F1. These interest you.
Difference are "old" records, only on F2. These (apparently) don't interest you.
Changed records, where there will be an F1 and an F2. You are only interested in the F1s.
The INCLUDE/OMIT you have already been shown will get you an empty output if the two files match completely, byte-for-byte, record-for-record.
You have two remaining situations. Records solely unmatched from F2 (so F1 output is empty). And unmatched records from F1 which you want to process (whether or not there are F2 records).
The F1 records are where 251,250,CH,EQ,C' '
To do this all in one step, you have three "states" I think you need to cover, and you have three different RC values (0, 4 or 16) with the added "complication" that 16 is produced when there is a problem with the control cards.
Personally, I'd probably go for 0 telling me there are unmatched F1 records for processing and 04 telling me there is not an output file for processing, but which a further step would have to be used to distinguish between the "matched entirely" state, and the "unmatched, but only unmatched on F2" - if you need to differentiate.
If you really have to set 8, use the IDCAMS to set to 8 when spotting a 4.
You now have all the bits you need to put the thing together. We're not aware of exactly the combinations you need, but you are, and we've covered them what you may need, and more. There are variations in how to do it, what codes to set. You have the option to certainly identify an empty OUTFIL with non-zero RC, and probably a data-containing OUTFIL with non-zero RC.
You should be able to sit back, go through everything, and work out what it is that you exactly need.
If you can't get it to work, show what you've tried and include and exact description of what you want, covering all situations. Someone may then put together the bits from what you've already been shown.
If you do get it by yourself, post it here, as it may well help someone else in the future.
You've got everything you need. You can do everything in SORT. You can know from one step whether you have a file which needs processing. For convenience (due to the prior use of RC16) you can differentiate the two no-output-to-process situations (if you need to) in a separate step, and probably by reading/attempting to read only one record (STOPAFT).
We've spent time on it, now it's your turn. Don't come back in five minutes just wanting it off pat, please.