IBM Mainframe Forum

I have two files, both LRECL=455, both with keys 1,32,A,81,39,A. Where the keys match, I need to replace the values from file2 33,38,CH in file1, same starting spot and length. I used the following code as a basis,

to get to

In the IFTHEN, why should it be looking for a B in position 456? Also, do I have this setup correctly to replace values from file2 in file1 when the keys match and to keep unpaired records in file1?

Thank you,
Brad

BGronli wrote:I have two files, both LRECL=455, both with keys 1,32,A,81,39,A. Where the keys match, I need to replace the values from file2 33,38,CH in file1, same starting spot and length. I used the following code as a basis,
In the IFTHEN, why should it be looking for a B in position 456? Also, do I have this setup correctly to replace values from file2 in file1 when the keys match and to keep unpaired records in file1?
Thank you,
Brad

BGronli,

Your syntax cards are correct. As for your question as to why you need to validate the indicator at position 456, you used JOIN UNPAIRED,F1 which writes out unpaired records from F1 as well as paired records. For paired records you can replace the contents from file 2 but for unpaired records , DFSORT does not know what to replace , so it fills with the default FILL character which is spaces thus by overlaying the original content. In order to preserve the original content we add an indicator at the end and also the file2 contents in a temp location (usually at the end) and then we validate the indicator to overlay file 2 values on to file1.

? on the REFORMAT statement indicates a 1-byte indicator is to be included in each joined record. The indicator will be set to one of the following values in each paired or unpaired joined record, as appropriate:

'B' - the key was found in F1 and F2.

'1' - the key was found in F1, but not in F2.

'2' - the key was found in F2, but not in F1.

So B denotes a matching record and we are only overlaying the contents of file2 using IFTHEN statement.

Check this link for a detailed explanation of JOINKEYS

http://publibz.boulder.ibm.com/cgi-bin/ ... E1CA60/4.0

skolusu,

Thank you for your earlier response and I apologize for not returning sooner to do so. With regards to your example, should the output file be larger than the file being updated? When I run the following:
SORTJNF1 has 823,433 records. SORTJNF2 has 54,627 records. I would think that SORTOUT should also have 823,433 records, however, it has 1,089,719. Any ideas?

BGronli wrote:skolusu,

SORTJNF1 has 823,433 records. SORTJNF2 has 54,627 records. I would think that SORTOUT should also have 823,433 records, however, it has 1,089,719. Any ideas?

I am guessing that you have duplicates on the keys you matching in both files. For ex: if you have 3 duplicates in file1 for a key and file2 has 5 duplicates for the same key, the resulting output will be 3 X 5 = 15 rows.

So Check if you have duplicates and if you don't want a cartesian product , then you can eliminate duplicates using JNF1 or JNF2. Let me know if that is what you want and I will show you a way to do it.

I did find duplicates and the problem was in the statements. They both should have been (1,32,A,81,39,A). Once I corrected that and ran, I have the correct number in the SORTOUT, 823,433.

Thanks again for the help.

I had a similar question in another post and had used the above sort/join suggestion.. I wanted to thank users Skolusu and BGronli for the great help... Also I'm not sure how to thank them and that is why I was posting in the thread!

There is a "thumbs up" icon on the right of the row of icons above a post.

but...Greod123 has not been seen in years and Kolusu, who is a DFSort developer, does not participate in these forums but has his own.

These users thanked the author NicC for the post:

Oreod123 (Tue Jul 02, 2019 5:52 pm)