You may get an exception similar to one below when trying to use CCSID 13124 to connect to AS/400 database using db2 jcc type 4 driver :
Exception result Set Not Returned
Target SQL Exception: SQL_EXCEPTION (Error:-4220; SQLSTATE:(22021)
[JCC][(T4)][(10041)][4.18.60] Unsupported ccsid, encoding, or
SEVERE: SQL Query Failed: SELECT EMPNO FROM EMP.EMP01 WHERE NAME=‘JOHN'
FETCH FIRST 10 ROWS ONLY
Unsupported ccsid, encoding, or locale: "Cp836". ERRORCODE=-4220,
This statement fails with the -4220 on a simple execute() method call.
So it does not appear to be reaching a getAsciiStream or getString call at the time of the failure, it's throwing the error right at the time of execute.
Internally, the JCC driver uses UTF-8. So there will always be an implicit character conversion from the database codepage to UTF-8 when using the JCC driver, regardless of any other codepage settings at the client.
Differences in character conversion
When character data is transferred between a client and a server, the data must be converted to a form that the receiver can process.
For the IBM Data Server Driver for JDBC and SQLJ, character data that is sent from the data source to the client is converted using Java's
built-in character converters. The conversions that the IBM Data Server Driver for JDBC and SQLJ supports are limited to those that are
supported by the underlying JRE implementation.
A IBM Data Server Driver for JDBC and SQLJ client using type 4 connectivity sends data to the data source as Unicode UTF-8.
If a GRAPHIC column contains single-byte characters (an error condition), the DB2 JDBC Type 2 Driver performs character conversion during data retrieval without issuing an error, but the results might be incorrect. The IBM Data Server Driver for JDBC and SQLJ issues an error.
If character data other than ASCII data is retrieved from a CLOB column with getAsciiStream, the DB2 JDBC Type 2 Driver performs character conversion correctly during data retrieval. The IBM Data Server Driver for JDBC and SQLJ does not perform character conversion correctly. getAsciiStream should be used only for retrieval of ASCII data. For
other types of character data, use getCharacterStream or getString instead.
Those drivers use CCSID information from the data source if it is available. The drivers convert input parameter data to the CCSID of the
data source before sending the data. If target CCSID information is not available, the drivers send the data as Unicode UTF-8.
We can conclude hence that the problem is with JVM.
Checking missing class :
Please check which JRE you are using.
Under jre/lib check if you have rt.jar and charset.jar. Then look for ByteToCharCp836.class in the jar files and make sure it's not missing.
Under the OPT install path, look for are and check for file name charsets.jar, under file name like charsets-1.5.0_09.jar. Check if it has cp836.
jar -tvf charsets-1.5.0_09.jar | grep Cp836
jar -tvf charsets-1.5.0_09.jar.bak.20110802 | grep Cp836
If you get the error shown above, then you will not find Cp836 in the jar file.
IBM has a charset support for every CCSID IBM machines deal with.Sun JDK/JRE uses charsets.jar to provided character mapping between UTF-8 and various code pages. Sun has separate international installations and that localized install would not have all conversion classes. So you will need to obtain a full JDK installation.
It is best to use latest IBM JDK. It contains both rt.jar and charsets.jar containing the class file ByteToCharCp836.class.
Download here : https://www.ibm.com/developerworks/java/jdk/index.html
Some reference links on similar topics :
Accessing a iSeries DB2 (AS/400) database via JDBC http://www-01.ibm.com/support/docview.wss?uid=swg21959125
Using a JDBC Connector to connect to DB2 on iSeries (AS400)
Unsupported encoding Cp037 when using DB2© Universal JDBC Driver to connect to DB2 UDB for z/OS©
IT07334: JCC DRIVER THROWS AN EXCEPTION: UNSUPPORTED CCSID, ENCODING, OR LOCALE: "CP1047". ERRORCODE=-4220, SQLSTATE=22021