Re: Strange behavior of special characters in IFS source files

I'm afraid it isn't as simple as that, I have tested a small program with
danish characters
as constants in the IFS file with CCSid 1252:

stmt = 'test of special characters @ æøå/ÆØÅ';
except print;

*inlr = *on;
/end-free
oqprint e print
o stmt


And when it is executed it gives this in the print-file:
*...+....1....+....2....+....3....+.
test of special characters Ø {¦}/[@$

When I convert the DB2 source file to a IFS source file with CCSID 277 it
all
works as usual on a CSSID 277 machine.

Now CCSid 277 is not a very nice CCSid when you have to use FTP to transfer
back and forth with and editor in the middle, FileZilla dosn't seems to
work but a
mix of WinSCP and Visual Studio Code as editor does do the trick and
converts
the 277 file to 1252 and back again when it is stored.

BTW Visual Studio Code isn't a part of MS Visual Studio but a stand alone OS
free program that seems to be the successor of Nodepad++ and Sublime Text
with a lot of development plugin's - also RPG.

Combine WinSCP (that supports client passive FTP) and Visual Studio Core
and
you have a rather powerfull IFS file editor for any IBM i.

https://winscp.net/eng/index.php

https://code.visualstudio.com/

On Mon, Jun 5, 2017 at 4:52 AM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 04-Jun-2017 11:16 -0600, Henrik Rützou wrote:

I have a IFS SBCS source file that has CCSID 1252 and the
characters:

// test @ æøå/ÆØÅ

2F2F2074 65737420 4020E6F8 E52FC6D8 C50D0A // test @ æøå/ÆØÅ

When I compile it on a CCSID 277 (danish) machine it becomes this
in the compiler list:

// test Ø {¦}/[@$

@ is in ASCII x'40', in ebcdic-37 x'7C'
that in ebcdic-277 displays as Ø
Ø is in ASCII x'D8', in ebcdic-37 x'80'
that in ebcdic-277 displays as @

Am I missing something or is it only a compiler print problem?

What is described, appears to me, to be a compiler print "problem";
apparently a side effect per EBCDIC CP00500 [coincidentally, a Code Page
much like CP00037, for those characters] as choice for representing the
data from the UCS2 data. Seemingly, that effect holds, irrespective the
Character Identifier (CHRID) specification established for the printer
file. FWiW, a CHGJOB CCSID(*HEX) /* or instead, to CCSID(500) or CCSID(37)
*/ will cause the spooled data to appear with the expected glyphs, for
those characters, despite them not being the expected code points.

FWiW, the same effect might be seen using a job CCSID(37) compiling from
a PF-SRC member with CCSID(277); the spooled data would be the expected
CP00277 code points, but the /wrong/ glyphs would appear when viewing the
spooled file (DSPSPLF), because apparently, the CHRID for the printing
would have been established from the CCSID of the source.

--
Regards, Chuck

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD