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

Need to compare encrypted data using joinkeys in sort.


IBM Mainframe Forums -> DFSORT/ICETOOL
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
Febin

New User


Joined: 09 Nov 2010
Posts: 2
Location: Trivandrum

PostPosted: Mon May 28, 2012 8:29 pm
Reply with quote

My requirement is to compare the encrypted data like (y½›ÁhUÐz ð»\Ô) in 2 files and write the records from first file that do not have a match in the second file. I am using the following sort card. But all the records in the first file are written to the output file even when the second file has matching records. The file format for sort is automatically taken as BI.

Code:
//STEP01   EXEC PGM=SORT
//SYSOUT   DD SYSOUT=*
//CHEKASC  DD DSN=AAA,DISP=SHR
//WINASC    DD DSN=BBB,DISP=SHR
//SORTOUT  DD DSN=CCC,
//             DISP=(NEW,CATLG,DELETE),
//             DCB=(RECFM=FB,LRECL=70),
//             SPACE=(CYL,(100,50),RLSE)
//SYSIN DD *
  JOINKEYS F1=CHEKASC,FIELDS=(1,16,A)
  JOINKEYS F2=WINASC,FIELDS=(1,16,A)
  JOIN UNPAIRED,F1,ONLY
  REFORMAT FIELDS=(F1:1,70)
  OPTION COPY
/*
//*

I tried using the following control statements -
Code:
//JNF1CNTL DD *
  INREC BUILD=(1,16,UFF,TO=CH,LENGTH=16,17:53)
/*
//JNF2CNTL DD *
  INREC BUILD=(1,16,UFF,TO=CH,LENGTH=16)
/*

But this did not help. Please advise how to proceed.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Mon May 28, 2012 9:13 pm
Reply with quote

comparing encrypted data makes no sense unless You compare the whole records
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: Mon May 28, 2012 11:03 pm
Reply with quote

Are you sure of your recfms and positions of the fields?

Forget those CNTLs, I've no idea what they'd come up with.

If you want to see that the joinkeys works, just put some plain data as DD * for your input datasets. Then work out what you've overlooked.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Tue May 29, 2012 12:27 am
Reply with quote

Hello and welcome to the forum,

From what you have posted, it is not clear exactly what you want to compare. . . At least not to me icon_smile.gif

Nothing will be gained by trying to convert the encrypted data to character. . .

Suggest you try SuperC to compare these files.
Back to top
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India

PostPosted: Tue May 29, 2012 10:30 am
Reply with quote

Quote:
comparing encrypted data makes no sense unless You compare the whole records

Could you please let me know why this has to be done? Just want to know.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Tue May 29, 2012 11:28 am
Reply with quote

and my explanation was even wrong icon_biggrin.gif

the only thing that can be checked for a proper encrypted files is that they
are exactly the same

... because of the "diffusion paradigm" of encryption...
a bit value in some position might influence a bit in a completely different position ( depends also on the basic chunk size used )

for CBC enciphering the data generated depends on the previous data

for example given the two <blocks>
12345678aaaaaaaa

87654321aaaaaaaa

the encrypted values in positions 9-16 will be different because the data from the previous 8 byte chunk will be used to modify the encryption scheme for the second 8 bytes chunk.
and so on and so on

so position 9-16 of the original will match, the encrypted ones will not!

not a mathematical foolproof description, but enough to make understand some very very basics icon_biggrin.gif

at the MICRO level

at the macro level with a proper implementation the data of the first record will influence the data of the 10000000th records

in other words given two files with exactly the same 1000000 records
with one byte different somewhere , they will NOT match anywhere
apart the data up to the first original difference.
Back to top
View user's profile Send private message
vasanthz

Global Moderator


Joined: 28 Aug 2007
Posts: 1742
Location: Tirupur, India

PostPosted: Tue May 29, 2012 11:59 am
Reply with quote

Thanks, Now I have some mental picture.
Back to top
View user's profile Send private message
Febin

New User


Joined: 09 Nov 2010
Posts: 2
Location: Trivandrum

PostPosted: Wed Jun 06, 2012 12:04 pm
Reply with quote

The same data was encrypted in different ways in the input files. That was the reason the sort did not work as expected. When I corrected the encryption method the records are displayed fine.

Thanks for your time.
Back to top
View user's profile Send private message
dick scherrer

Moderator Emeritus


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

PostPosted: Wed Jun 06, 2012 7:06 pm
Reply with quote

Good to hear it is working - thank you for letting us know icon_smile.gif

Do be aware that even though this compare worked, there may be false unmatches on some other data due to what Enrico explained.

d
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 -> DFSORT/ICETOOL

 


Similar Topics
Topic Forum Replies
No new posts How to split large record length file... DFSORT/ICETOOL 10
No new posts Compare only first records of the fil... SYNCSORT 7
No new posts Data set Rec-Cnt and Byte-Cnt Testing & Performance 2
No new posts JCL sort card - get first day and las... JCL & VSAM 9
No new posts SCOPE PENDING option -check data DB2 2
Search our Forums:

Back to Top