RE: Codepage issue?

The mind boggles.  You have a CCSID 37 file on a machine which has at least
one user at CCSID fff (the French CCSID).  That means the hashmark used in
the source code for your JDBC statement had the same hex value as the one
for the field name in the database file; somehow, the JDBC driver got
confused because the user's CCSID wasn't 37.

But now that begins to make sense.  As I think about it, I realize that the
data in the program is actually stored in Unicode, and so not one, but TWO
translations occur all the time (at least for hard-coded literals in Java
programs):

1. Literals in your text file are entered in 8-bit EBCDIC, and the compiler
converts that to 16-bit Unicode when compiling the literal.

2. At some point the JDBC driver needs to convert the Unicode back to 8-bit
EBCDIC to validate the statement.  It uses the current CCSID of the job to
do that conversion.

What happened was the compiler on your machine converted the CP037 hashmark
x'7B' in the source code for your JDBC statements to the universal value of
the hashmark in Unicode (U+0023).

When it got translated back to EBCDIC under a user profile using the French
CCSID, you ended up with a x'B1', which no longer matched the field name on
the file.

Joe


-----Original Message-----
From: David Gibbs

Since the user profile had CCSID 37, and the file had a CCSID of 37, no
translation needed to occur.