I need to compare two files (A & B) i should replace the FILE A with FILE B when the keys are equal else i should not replace the FILEA, it should remain as it is.
File A Key Positions 1-10 and 16-23
File B Key Positions 1-10 and 11-18
The data to be replaced is 11-15 positions in FILE A from FILE B Positions 19-23
I am using SYNC SORT i tried using the following SORTCARD:
Joined: 09 Mar 2011 Posts: 7312 Location: Inside the Matrix
Isn't it going to be the records on FILE A which do not match FILE B?
Your JOIN gives you all the paired records, plus unpaired records from FILE A. For the paired records, the REFORMAT will be processed, for the unpaired records not. Then the OUTREC will find data for the records which have been REFORMATted but just spaces for the unpaired records.
Anyway, samples of input data which would show matching and non matching conditions, output data for that, and JCL as Dick has asked already.
Joined: 10 May 2007 Posts: 2418 Location: Hampshire, UK
Note: using code tags retains spaces so that you do not have to do what you just did. See the button labeled 'Code' just above the message body box? Highlight the text to be 'coded' and click on that button. But you knew that because it has been mentioned so many times recently and you do read everyone's posts, don't you, just in case you learn something useful or find the answer to your query without having to post anything?
Here I am assuming that if you dont find match on file 2 then felds from file 2 will be spaces.
Also your matchging kely will never have spaces iin the begining. If it is the case then you may need to have FILL character as per suggested by Bill.
You could try something like the following. I have used SYMNAMES to make it self-documenting. You can use more meaningful names than I, as you know the data. You can even give them the same names as Cobol or other languages. I am assuming that SYNCSORT has the ? and WHEN=NONE.
The problem with relying on the FILL character might not bite you in your example, but if you then copy those sort cards for another requirement where the field you are testing can validly contain the fill character, then you have a mess.
I have relocated your "SORT" statement to a more common position, as that is where most people will look for it to be. It will not affect the processing. The order you put the cards in does not affect the order that SORT will process them in (assuming valid syntactically).