Joined: 30 Jun 2010 Posts: 85 Location: Toronto, ON
Hi,
I am comparing two files using Sort JOINKEYS operation on fields having below COBOL declations.
i| S9(9) comp-3
ii| 9(9) comp-3
The problem, that I am facing while comparing the two is, the sign nibble of the first field is 'F' and the same is 'C' for the second field although both are packed decimals, contain the same values and both are positive.
I have found that this depends on the field declaration. If the declaration is S9(9) comp-3 it will be 'C' and if it is 9(9) comp-3 then it will be 'F'.
As this was creating problem in the JOIN operation I added a sort step before the JOIN to manually convert all the 'F' of first file in that field's nibble position to 'C'. This fixed the issue temporarily but this approach is ambiguos and error prone for the later processings.
Is there any other way or option in JOINKEYS by which I could match them rightaway?
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hello,
Quote:
This fixed the issue temporarily but this approach is ambiguos and error prone for the later processings.
Please clarify. If the signs are made to match, where is the ambiguity/error proneness?
Hopefully, neither of these fields are ever used as a key or an index anywhere in the system. . . This too will cause a mismatch when trying to "read" by key randomly.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
ksouren007,
Your analysis is correct, the values are equivalent yet sufficiently different for the join not to work. Problem well stated, so 1/2 the job done already. Well done.
The best thing would be for both fields to be defined the same in the programs producing the files.
They should not be different definitions in the first place, to my mind. Involve your boss as someone has to find the first place the discrepency in definition occured and ensure that everything is corrected.
Of course, if there is somehow some genuine business reason for the difference, then your existing temporary solution can be expanded with a little bulletproofing to deal with the discrepencies in the field.
Check also that the existing data matches the existing definitions, as if they don't it would be a symptom of some other problem. I'd even check that all on one file have "C" and all on the other have "F". That's what I'd do personally. Mostly it'll be a "waste" of (not much) time, but once in a while it will save you hours of work, and maybe even more than that.
Joined: 30 Jun 2010 Posts: 85 Location: Toronto, ON
Thanks all...!!
Just now I'm thinking of a another way, that i will try and see whether it works!
I will convert both the fields to ZD in two temporary files before the JOINKEYS comparison. Match them excluding the sign position and convert them back into the output file to PD while doing OUTREC.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
It is up to you, but I'd go for the investigation and possible program fix. I'd always want to know if there are other consequences whenever "wrong" data turns up.
Joined: 07 Dec 2007 Posts: 2205 Location: San Jose
ksouren007 wrote:
As this was creating problem in the JOIN operation I added a sort step before the JOIN to manually convert all the 'F' of first file in that field's nibble position to 'C'. This fixed the issue temporarily but this approach is ambiguos and error prone for the later processings.
Is there any other way or option in JOINKEYS by which I could match them rightaway?
ksouren007,
You don't have to use a different step to change the F sign to C sign. You can do it all in JOINKEYS step itself
I assumed that your PD field starts in pos 10 in both files and the lrecl of both files is 80. The output is 161 bytes ( 80 bytes of file 1 + indicator + 80 bytes of file 2).
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Souren,
Note that if you need to keep the PD fields as they originally were (C or F sign), you could add the normalized fields (TO=PDC) at the end of each record and do the JOINKEYS on those fields so you wouldn't have to change the original fields.
If you need further help with your DFSORT JOINKEYS job, show the job you're using, explain what you're trying to do and give the RECFM and LRECL of the input files, and we'll show you how to fix it.
Joined: 30 Jun 2010 Posts: 85 Location: Toronto, ON
Bill,
Both the files with which I am working with belongs to different sub systems on which I dont have the control over. Also that would involve a much bigger impact analysis for my task.
Skolusu,
I was not familiar with JNF1CNTL statement and could not map my requirement to that.
Joined: 15 Feb 2005 Posts: 7129 Location: San Jose, CA
Quote:
Is there a reason as to why you did not use JNF1CNTL and JNF2CNTL?
The reason is that ksouren007 is using Syncsort (I can tell from his control statements).
ksouren007,
With DFSORT, you could do it all in one pass by using JNFxCNTL, but Syncsort doesn't support JNFxCNTL so you would need multiple passes.
The title of this Forum is "DFSORT/ICETOOL" and amazingly enough it's for questions on DFSORT and DFSORT's ICETOOL. I'm pretty sure you're using Syncsort, not DFSORT - please ask Syncsort questions in the JCL Forum. Kolusu and I are DFSORT developers. DFSORT and Syncsort are competitive products. We're happy to answer questions on DFSORT and DFSORT's ICETOOL, but we don't answer questions on Syncsort.
Joined: 30 Jun 2010 Posts: 85 Location: Toronto, ON
Frank,
I am using Syncsort indeed but I had got helps from this forum(From you too) earlier on Sorting that's y feel comfortable to post my queries here.
Neways will take care of the title's of forum going forward.
Also I understand from you that I need the multiple passes here so that answers my question.
Thanks for all your help.
Joined: 09 Mar 2011 Posts: 7309 Location: Inside the Matrix
ksouren007 wrote:
Bill,
Both the files with which I am working with belongs to different sub systems on which I dont have the control over. Also that would involve a much bigger impact analysis for my task.
[...]
OK, so CYA time. Write a memo to your boss outlining the differences and expressing your concerns for the integrity of the data and that you would like a resolution to your concerns before you are happy with the solution to implement for your actual requirment.
Then, if it all hits the fan big time, no-one can blame you.
Otherwise, if you are the person to know about it, and you didn't do anything, then someone is liable to chop your legs off at the knee when it hits the fan and they find you were anywhere near it :-)
Joined: 30 Jun 2010 Posts: 85 Location: Toronto, ON
Bill
They know it.They work with this for years.That works fine.They dont want to bother about it as long as that works fine.So they dont want to change it.
Then, Why do I take the headache and not finish my tiny long requirement like above before cooling my heels off on the upcoming long weekends???
