On 19-Aug-2016 06:22 -0700, Stuart Rowe wrote:
So I saved a member "as" a different name in a different source file
in a different library. I do it often enough.
I noticed that every time I do so, certain characters are not copied
correctly. The source files are the same length and CCSID. I opened
the "from" member and made no changes. When I save it to the SAME
source file, different name, works OK. When I save it to a DIFFERENT
source file, regardless of name, the characters get messed up. It
must be something RDi is doing when saving from the editor (or the
cache) because when I copy them using PDM or "Copy/Paste" from Remote
System View, they look just fine.
Here's an example
Given this comment block (the first line is made of "overline"
characters, sometimes called "macron", and you can key them using
alt-0175 on the numeric keypad if you have one) :
That would be the code point 0xAF in ASCII CCSID 1252, the character
ID SD310000 aka Macron Accent. For lack of a matching character\glyph
in EBCDIC CCSID 0037, the best-fit replacement character would be a
map\translation to the code point 0xBC in EBCDIC CCSID 37, the character
ID SM150000 aka Overline.
*¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
<snip>
*_____________________________________________________________________________________________
After "Save As..." finishes, it looks like this:
*���������������������������������������������������������������������������������������������
<snip>
*_____________________________________________________________________________________________
The above "�" character is known as the /replacement character/,
which I expect is a visual representation [¿a variant?] of the
substitution "␚" character which would be used to indicate that an
appropriate character\glyph could not be found to represent the
character [e.g. in the editor being used, into which the text was
pasted] that was originally there.
I expect that a similar outcome would have been seen for what a
translation from the ASCII macron character would effect when
translating to EBCDIC without a /best-fit/ implementation; i.e. rather
than the translation code finding what is deemed to be an appropriate
alternative character, the effect would have been the EBCDIC 0x3F which
is the /Substitution Character/. Noting, the 0x3F actually has a
rendered glyph on a[n original hardware] 5250 display, but I do not
recall what, and as a value less-than 0x40, the various /character/
visualizations, e.g. in .PDF graphic form, do not include that
character; all effective or actual control-code characters are excluded
in such documentation.
Well turns out I cannot represent exactly what it looks like here.
The top line is all tall rectangles, not question marks like you may
see above.
The actual code point stored in the source physical file member, and
the actual CCSID of the file would be of interest; the Display Physical
File Member (DSPPFM) and Copy File (CPYF) both have /hex/ display
features to reveal the code point representing each single-byte
character; the latter with *HEX on the Output Format (OUTFMT) parameter,
though possibly requiring also OUTPUT(*PRINT) specification.
I suspect possibly that the 0xBC in the EBCDIC-tagged PF-SRC is not
[¿consistently?] returning to the client as the originally typed 0xAF
[i.e. typed in as the 0d175], or the originally typed 0xAF is not being
sent [¿consistently?] to the server as the expected 0xBC; in the latter
case, possibly stored as 0x3F, and the former case possibly stored as
0x7F at the client [that when copied\pasted into your email client
appears as the glyph for the multi-byte UTF8 character 0xEFBFBD]
Is there a way to avoid this other than to use PDM or CPYF? The
"Save As..." thing in RDi is nicer to use cause I'm right there, you
know?
Irrespective the origin for the changing character, the problem can
be avoided generally, by avoiding the use of ASCII characters that do
not have an equivalent in the EBCDIC code page being used when storing
the data; i.e. if the ASCII data is going to be stored as EBCDIC on the
server [thus is not to be stored in ASCII on the server], then use only
ASCII data within the editor that is known to have a direct\expected
mapping into the same character+glyph in the EBCDIC CCSID of the data
that will be stored on the server. For this specific scenario then, do
not use the macron character in the client copy of the source; the
/dash/ "-' character is well supported in both encodings, so should
transport\translate well betwixt, and should serve as a
reasonable-enough, even if visually-undesirable, substitute for the
effect of an overline character:
*--------------------------
<snip>
*__________________________
midrange.com
