IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Joinkeys Compare for different Cobol Declaration fields


IBM Mainframe Forums -> JCL & VSAM
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
ksouren007

New User


Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON

PostPosted: Tue Jul 26, 2011 2:03 am
Reply with quote

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?

Please advice.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 2:20 am
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 3:00 am
Reply with quote

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.
Back to top
View user's profile Send private message
ksouren007

New User


Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON

PostPosted: Tue Jul 26, 2011 3:08 am
Reply with quote

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.

This mught avoid all this confusion.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 3:18 am
Reply with quote

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.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19243
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 3:19 am
Reply with quote

Hello,

Quote:
This mught avoid all this confusion.
And it mught not. . . icon_smile.gif

Zoned Decimal has both an F and a C sign for positive as far as i recall. . .
Back to top
View user's profile Send private message
Skolusu

Senior Member


Joined: 07 Dec 2007
Posts: 2205
Location: San Jose

PostPosted: Tue Jul 26, 2011 3:21 am
Reply with quote

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).

Code:

//STEP0100 EXEC PGM=SORT                   
//SYSOUT   DD SYSOUT=*                     
//PDF      DD DSN=Your PDF input file1,DISP=SHR
//PDC      DD DSN=Your PDC input file1,DISP=SHR
//SORTOUT  DD SYSOUT=*                     
//SYSIN    DD *                           
  OPTION COPY                             
  JOINKEYS F1=PDF,FIELDS=(10,5,A)         
  JOINKEYS F2=PDC,FIELDS=(10,5,A)         
  JOIN UNPAIRED                           
  REFORMAT FIELDS=(F1:1,80,?,F2:1,80)     
//JNF1CNTL DD *                           
  INREC OVERLAY=(10:10,5,PD,TO=PDC,LENGTH=5) 
//JNF2CNTL DD *                           
  INREC OVERLAY=(10:10,5,PD,TO=PDC,LENGTH=5) 
//*
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Developer


Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA

PostPosted: Tue Jul 26, 2011 4:09 am
Reply with quote

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.
Back to top
View user's profile Send private message
ksouren007

New User


Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON

PostPosted: Tue Jul 26, 2011 9:54 pm
Reply with quote

Thanks all again.

Frank, I followed the same below approach. Is it fine or I can include the SORT01 & SORT02 steps inside my JOIN step itself and optimize more?

1. SORT01 - First input file(FB). I have moved and converted the matching criteria key at the end now.

SORT FIELDS=COPY
OUTREC FIELDS=(1,418,2,5,PD,TO=PDC),CONVERT

2. SORT02 step - Second Input File(FB).

SORT FIELDS=COPY
OUTREC FIELDS=(5,1,6,4,
10,1,11,3990,6,4,PD,TO=PDC,10,1,PD,TO=PDC),CONVERT


3. And joined as below.

Code:
 //SYSIN     DD *                                         
  JOINKEYS FILE=F1,FIELDS=(New Key Position)                         
  JOINKEYS FILE=F2,FIELDS=(New Key Position)                         
  JOIN UNPAIRED,F1                                         
  REFORMAT FIELDS=(F1:1,418,F2:2,5),FILL=X'FF'             
  SORT FIELDS=COPY                                         
  OUTFIL FILES=01,                                         
  INCLUDE=(419,1,BI,NE,X'FF'),             
  OUTREC=(1:1,418)                                         
  OUTFIL FILES=02,                                         
  INCLUDE=(419,1,BI,EQ,X'FF'),             
  OUTREC=(1:1,418)                                         
 /* 
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 10:16 pm
Reply with quote

Souren,

You were off to a good start, and your sort coding is progressing.

One last time from me: why do the fields have different definitions?
Back to top
View user's profile Send private message
Skolusu

Senior Member


Joined: 07 Dec 2007
Posts: 2205
Location: San Jose

PostPosted: Tue Jul 26, 2011 10:36 pm
Reply with quote

ksouren007,

Is there a reason as to why you did not use JNF1CNTL and JNF2CNTL?
Back to top
View user's profile Send private message
ksouren007

New User


Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON

PostPosted: Tue Jul 26, 2011 10:42 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Developer


Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA

PostPosted: Tue Jul 26, 2011 10:43 pm
Reply with quote

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.
Back to top
View user's profile Send private message
ksouren007

New User


Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON

PostPosted: Tue Jul 26, 2011 10:54 pm
Reply with quote

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.
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 11:05 pm
Reply with quote

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 :-)
Back to top
View user's profile Send private message
Frank Yaeger

DFSORT Developer


Joined: 15 Feb 2005
Posts: 7129
Location: San Jose, CA

PostPosted: Tue Jul 26, 2011 11:08 pm
Reply with quote

Quote:
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.


Probably because you didn't mention that you were using Syncsort and I didn't see anything in your posts that indicated you were using Syncsort.
Back to top
View user's profile Send private message
ksouren007

New User


Joined: 30 Jun 2010
Posts: 85
Location: Toronto, ON

PostPosted: Tue Jul 26, 2011 11:19 pm
Reply with quote

Bill icon_biggrin.gif

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??? icon_biggrin.gif
Back to top
View user's profile Send private message
Bill Woodger

Moderator Emeritus


Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix

PostPosted: Tue Jul 26, 2011 11:35 pm
Reply with quote

Souren,

OK, I don't like it (not that it matters), but it is their funeral, not yours or mine. Enjoy your weekend when it comes!
Back to top
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> JCL & VSAM

 


Similar Topics
Topic Forum Replies
No new posts COBOL sorting, with input GDG base COBOL Programming 7
No new posts Need help with ADABAS query (COBOL-AD... All Other Mainframe Topics 0
No new posts JCL sort to compare dates in two file... DFSORT/ICETOOL 2
No new posts Replacing FILLER with FILLER<SeqNu... DFSORT/ICETOOL 2
No new posts Pull data using date difference betwe... DB2 6
Search our Forums:

Back to Top