In addition, I've worked with DB2 previously on a z/OS system utilizing the type driver supplied by IBM. The database was expecting EBCDIC and the data I was working with in the Java world was ASCII coming in from an XML document encoded in UTF-8. The JDBC driver did a marvelous job of converting the ASCII to EBCDIC for me without me even needing to think about it. However, one thing that you must be aware of is that there are ASCII characters that do not map to EBCIDIC characters and there are EBCDIC characters that do not map to ASCII characters. This is something that I spent a great deal of time on, trying to map some obscure characters to the back-end system because it was required. The end result was utilizing triggers to get around some of the issues.
Anyway, just be aware of the character mapping between the two encoding.
Chris Mathrusse
[EMAIL PROTECTED]
Sybase, Inc
One Sybase Drive
Dublin, CA 94568
(925) 236-5553
| Christopher Lamey <[EMAIL PROTECTED]>
11/21/2007 11:39 AM
|
|
You'd have to look at every character of every parameter to find the problem
character, so looking at a few in the debugger doesn't mean much. Plus it
could be that they are valid UTF-8 characters, which would be fine in Java,
but the db isn't setup for that encoding.
Running the program on z/os will use the default encoding of the os, which
is most likely the same as the db encoding.
I don't know much about DB2 and even less about z/OS, but it looks like you
can use either UNICODE, ASCII, or EBCDIC. This is specified on source and
target table creation:
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.
db2.ii.doc/admin/te0x0002.htm
So you need to figure out the encoding of your db. My guess is that it's
either ASCII or EBCDIC.
Then you need to look at the encoding of the source data for your
parameters. Is it from a flat file or from another db?
Once you know where the encoding disconnect is, you can then figure out what
to do about it.
Cheers,
Chris
On 11/21/07 12:15 PM, "Ralf Assmann" <[EMAIL PROTECTED]> wrote:
>
> If I debug the code, the parameters to the sqlmap can be read, so in
> Java there seems not to be an encoding problem. If we are running our
> programm on z/os itself, the error also does not occur.
>
> Ralf
>
>
> Christopher Lamey schrieb:
>> It looks like the parameters to the sqlmap are in an encoding that the db
>> doesn't support. Most likely an extended character in one encoding that
>> isn't valid in another.
>>
>> What encoding is the db using?
>>
>> What encoding are the parameters coming in from? Java will use UTF-8
>> internally, but if you're reading data from a file encoded with windows-1252
>> there could be a character causing trouble.
>>
>> On 11/21/07 10:08 AM, "Ralf Assmann" <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Hi there,
>>>
>>> we have the following problem using iBATIS on a local machine (win2000)
>>> connecting a database at a remote host (db2 on z/os). We are using a jcc
>>> type 4 driver of IBM.
>>>
>>> While calling the ...queryForList(...)-methode of iBATIS -
>>> queryForObject(...) will bring the same result/error -, the following
>>> error occurs:
>>>
>>> --- The error occurred in <xml-file>
>>> --- The error occurred while applying a parameter map.
>>> --- Check the <statement>-InlineParameterMap.
>>> --- Check the statement (query failed).
>>> --- Cause: com.ibm.db2.jcc.b.DisconnectException: encoding not
>>> supported!! DB2ConnectionCorrelator: GA6F0608.G460.C188390D477C
>>>
>>> The iBATIS-error itself occurs in method executeQuery(...) of class
>>> SqlExecutor.class at line "ps.execute();".
>>>
>>> Using the same driver while preparing an own prepared statement and
>>> executing it (plain jdbc without iBATIS), everythings works well and the
>>> result will be delivered. So it seems not to be a driver error ...
>>>
>>> Does anyone has an idea what happens there?
>>>
>>> Many thanks.
>>>
>>>
>>> Ralf
>>>
>>>
>>>
>>
>>
