If the word is "café" in the text file, it should be "café" in the PF after the import.
The PF is 65535 which prevents CCSID conversion.
Good article. I found that site a few months ago. The posts are all old, but many are still applicable.
-----Original Message-----
From: John Yeung [mailto:gallium.arsenide@xxxxxxxxx]
Sent: Tuesday, February 13, 2018 4:51 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: CPYFRMSTMF & character conversion
On Tue, Feb 13, 2018 at 5:15 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
This character needs to stay as-is:
É
But that requires translation!
Right. If you really pay attention to what he's saying, he wants the
*conceptual* character to stay the same. Actually, he wants *all* the conceptual characters to stay the same. The characters, when encoded in code page 1252 (as they are in the stream file), are exactly the way he wants them.
But presumably the encoding of the PF isn't code page 1252, and almost definitely shouldn't be. If the contents of the PF are going to be interpreted as code page 37 data, then of course the *bytes* are going to have to be different than what's in the stream file, to preserve the *characters*.
I think it's worth bringing up this link again:
https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/
I know it's a long article, probably longer than it has to be for the information it conveys. But it is SO. MUCH. EASIER. to deal with encoding issues and to talk about them when everyone at least has reached the minimum level of understanding described in that article.
The minimum of the minimum for me is to learn the distinction between characters and bytes, and to be religious about keeping those concepts distinct.
John Y.
midrange.com
