Hi, we have two VB files (496 length including RDW). Now i have to segregate the input file based on a key. If this key is present in second file i have to write that record to MATCH file (Out file1). If not then i have to write file1 records to UNMATCH file (Out file2). Here the key is in hexa decimal format.
Joined: 17 Oct 2006 Posts: 2481 Location: @my desk
Sreenivas,
Welcome to the forums.
It does not matter in which format your key is, you just need to mention the starting position and length of the key-field in both the files in the JOINKEYS statement provided key-fields in both the files have the same format and length.
Thanks for the quick response. Please find the below code which i am using. The hexa decimal number is at 9-11 position. If i exclude the hexa part in the key, it was giving the correct result. Otherwise , it is giving incorrect result. Please help.
I think you forgot to take into account the 4-byte RDW. The first byte of sample data shown is really position 5. Therefore, (20,5) is C1A35 in the first record.
Sreenivas,
Quote:
If this key is present in second file i have to write that record
If you mean that you want the matched record from File2 written to the first OUTFIL, then modify the code as follows:
Joined: 23 Nov 2006 Posts: 19243 Location: Inside the Matrix
Hi Alissa,
Quote:
I think you forgot to take into account the 4-byte RDW
Yup - Didn't forget - left it out intentionally due to the leading x'40'. Also because x'1D7' = 471 and the original "spec" is "496 length including RDW".
My guesser wasn't working so well
I didn't look at the code and probably should have. . .
I want the matching records of file 1 should be written to Match file.
This logic is working when i specify the single key (20,5,A);
Also, when i specify two keys (8,1,A) and (20,5,A)
But it is giving the empty MATCH file when i specify three keys (8,1,A), (9,3,A) and (20,5,A).
The reason for this is , the key (9,3,A) - the format here is hexadecimal value (It is not Packed decimal where the sign is speified in the last nibble).
PS: 9,3 gives the number (which is in hexa format in the record). It will never have a nagative value.
All JOINKEYS fields are treated as binary format for purposes of comparison during the match processing.
With the sample data you provided, (9,3) does not match, so I would not expect there to be any matched records in the output. In File 1, the value is X'06DD26' whereas the value in File 2 is X'06DD27' . They simply don't match. If this is not the data you expected in the key field, then I would recommend that you verify your offsets.
