On Thu, Dec 29, 2016 at 12:08 PM, Smith, Mike
<Mike_Smith@xxxxxxxxxxxxxxxx> wrote:
Just to be clear this is how the data is showing up after the cat command
"FNAME","LNAME""SASA","ACKAR""JAMES","ADAMS""AMY","ADKINS""ERNEST","ADKINS"
This is how it should show up.
"FNAME","LNAME"
"MICHAEL","ALBERT"
"FRANCES","ALDERSON"
"JONATHAN","ALDRIDGE"
Actually, this is not the way to be clear. I mean, I can make an
educated guess, based on my experience and on your previous messages.
But your previous messages were clearer. The issue is, when you are
having problems with encoding, the clearest thing to do is give a hex
dump. Barring that, you need to at least say how you are looking at
the data (in other words, are you using Notepad, Excel, DSPF at a CL
prompt, cat command in QSH, etc.), because different methods will
render the data differently.
In one of your previous messages, you said your hex 0D0A line endings
became hex 0A. This is consistent with what I observed when using
methods which involve interpreting the data as text and then
potentially re-encoding it.
However, the -c option on the cat command should not be subject to
that, because it explicitly doesn't interpret the data. Please share
the EXACT command you are using. And be sure to use CHGATR to set the
CCSID of the output file to the same CCSID as the input files, after
the cat is complete. (The procedure isn't guaranteed to work if the
two CCSIDs on the input files are not the same as each other. It also
isn't guaranteed to work if the second file has a BOM; but if the only
CCSIDs you are seeing are 819 and 1208, and they are accurate, then
there shouldn't be any BOMs.)
John Y.
midrange.com
