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.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.