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.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.