RE: Codepage issues with the slash character

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: David Gibbs
>
> I've got an odd problem with code pages ... in one of our programs, the
> users enters an IFS path... which we then validate (using some API calls).
>
> Most paths begin with a back slash "\" character (for backwards
> compatibility, I think) ... and our program (RPG IV) checks the first
> character to make sure it's a backslash.

Okay, this is interesting.  You say the user enters a backslash as part of
an IFS path.  Are you using a green screen to prompt for the path?  If so,
the value will be stored as x'48' for CCSID 280, and x'E0' for CCSID 37 (see
below).


> This works fine on our machine (US based, code page 37) ... but on one of
> our customers machines in Italy (code page 280) our program is looking at
> the first character of that field and seeing something OTHER than a
> backslash (kind of a cents sign with a tail, don't know what it's called).

This is a bit strange, but not if you're shipping compiled code.  How are
you looking at the first character?  Comparing to a hex value?  Or to a
literal constant?  If it's a literal constant, you can fix the problem by
recompiling the program with the correct CCSID.


> To be honest, I really don't expect a character as basic as a slash or
> backslash to have a different hex value in two major language sets.

You'll be disappointed here.  The backslash is NOT a basic EBCDIC character,
and definitely has different values in different countries, from x'E0' here
to x'48' in Italy (x'EC' in Germany, x'71' in Finland... you get the idea).
A great list of these CCSID character maps is:
http://www.pdfing.com/Win/ScsCodePage.pdf.


> How are you supposed to deal with these kind of differences?

Several options.

First, use "standard" characters (the slash is standard, BTW).
Second, if you must use "moving" characters, don't test by hex value.  In
this case, any program that tests by literal must be recompiled for the
correct CCSID.
Third, use an API to convert the character to test from EBCDIC to ASCII,
then test the hex value of the ASCII character!

As a little historical background, SSA had an entire project (run by yours
truly) that removed non-international characters from all of our code.
These included "$", "#" and "@".  Basically, we went through every field
name and removed those letters, then generated unique names when collisions
occured.

We had to also run a decency check.  For example, the simple
internationalization rules had less than desirable results in the case of a
field like company number of checks, or CO#CKS.


Joe