Type-4 connectivity: Against informix data server, an
insert or update query sometimes fails if a target table
contains a DATETIME column. The SQLException "Execution
failed due to a distribution protocol error that caused
deallocation of the conversation. A DRDA Data Stream
Syntax Error was detected. Reason: 0x12. ERRORCODE=-4499,
SQLSTATE=58009" is reported by the driver. This issue has
been fixed. (RTC 74870)
Type-4 and Type-2 LUW Connectivity: When connected to
iSeries server, driver throws an SQLException with SQLCODE=-204
when
DatabaseMetaData.supportsResultSetType() API is invoked.
(RTC 72105)
All connectivities: The queryAccelaration and
queryAccelarationEnbale properties passed into the
DB2Connection.reuseDB2Connection( ) api do not take
effect. This issues has been fixed. (RTC 33177)
All connectivities: When calling a versioned stored
procedure on DB2 for z/OS, the driver throws an
SQLException with ERRORCODE=-4472 with a message "cannot
get the describe information for the calling stored
procedure." This happens when more than one versions of
the stored procedure exists. The problem has been fixed by
ensuring that the driver uses the currently Active version
of the stored procedure for determining it's metadata.
(RTC 66679)
Type-4 connectivity: If a connection is attempted to a
PureScale HADR cluster when it is in standby mode, the
driver receives a SQL error wih ERROCODE -1776 from the
server. If this occurs on the very first connection, the
driver would not have received a server list containing an
address for the alternate cluster. In such a case, the
driver needs to check if a cached server list for this
cluster is available on disk and if found, use it to
reroute the connection to the alternate cluster. However,
it is seen that even though the cached server list exists,
the driver does not consult it in such a scenario and
returns a connection failure SQLException with ERRORCODE
-1776 to the application. (RTC 67068)
Type-4 connectivity: The driver throws an SQLException
"Unsupported ccsid, encoding, or locale: "Cp1047".
ERRORCODE=-4220, SQLSTATE=22021" when querying data with
CCSID 1047. The problem has been fixed. (RTC 65970)
Type-4 connectivity: The driver throws an SQLException
"Unsupported ccsid, encoding, or locale: "GBK".
ERRORCODE=-4220, SQLSTATE=22021" when running under a
non-IBM JRE. (RTC 63278)
Type-4 connectivity: A batch of INSERT statements is
submitted where 1) sendDataAsIs property is set to true,
2) one of the target columns is of CHAR type, 3) setNULL (
) api is used to set the CHAR column to null in one of the
batch parameters input and, 4) in another input of batch
parameters for the same CHAR column setObject( ) api is
used to a specify a non-null object value. The execution
of such a batch via executeBatch() api fails with an
SQLException "Parameter types must match that of previous
batched types when using sendDataAsIs = true ERRORCODE=-
4474, SQLSTATE=null". This problem has been fixed.
(RTC 37911)
Type-4 connectivity: If a connection to DB2 z/OS is
established through a DB2 Connect Gateway, then even if
queries are cancelled from the client side, they continue
executing on DB2 z/OS server. This occurs because JDBC
driver by default uses
INTERRUPT_PROCESSING_MODE_CLOSE_SOCKET (2) against DB2 for
z/OS and if the connection is established through a DB2
Connect Gateway, the CLOSE_SOCKET interrupt mode does not
generate an interrupt on the DB2 for z/OS server. With
this APAR, this problem is fixed by not defaulting the
interrupt processing mode to CLOSE_SOCKET mode (2) if a
connection is through a DB2 Connect Gateway. (RTC 68037)
SQLJ ALL Connectivities: SQLJ trace generator modified with
lazy initialization and improved overall performance
(RTC 74421)
SQLJ All connectivities: In an sqlj program, if
setMaxRows( ) is specified and a SELECT INTO statement
gets a resultset with zero rows, a NullPointerException
occurs when accessing the resultset. This problem has been
fixed. (RTC 64893 )
Type-4 Connectivity: JCC driver attempts to load the native
library even for a T4 connection in CICS environment.
This results in the below exception.
"com.ibm.db2.jcc.am.SqlException: [jcc][10389][12245][4.15.99]
Failure in loading native library db2jcct2zos4_64, java.lang.
UnsatisfiedLinkError: db2jcct2zos4_64 (Not found in
java.library.path): ERRORCODE=-4472, SQLSTATE=null "
and JCC driver fails to establish a T4 connection through
Datasource or DriverManager in CICS environment.
The exception reported is as below.
"com.ibm.db2.jcc.am.SqlFeatureNotSupportedException: [jcc]
[10247][10035][4.15.120] Type-4 connectivity not supported
under CICS, IMS, or Java SP environments. Use Type-2
connectivity only. ERRORCODE=-4450, SQLSTATE=0A504 "
This issue has been fixed.(RTC 62607).
Type-4 and Type-2 LUW connectivity:
java.lang.ArrayIndexOutOfBoundsException occurs when
connecting to DB2 LUW 10.5 server through a DB2 V97 or
lower gateway. This issue has been fixed. (RTC 74641)
All connectivities: With Java 8, a
"java.lang.NoClassDefFoundError:
sun.io.CharToByteConverter" exception may be seen when
accessing character data or when attempting translation of
an SQLJ program. This issue has been fixed in the driver.
(RTC 59939)
All connectivities: With Java 8, the exception
"java.nio.charset.MalformedInputException" may be seen
when accessing UTF-8 character data. For example,
accessing data in a CLOB column using the ResultSet
getString( ) api may result in this exception.
The UTF-8 rules in Java 8 have been made stricter and some
character encoding sequences that were considered valid
until Java 7, may fail with the
java.nio.charset.MalformedInputException with Java 8. This
combined with how how DB2 for LUW stores UTF-8 data,
triggers this exception on a Java 8 client application.
For applications running with IBM JRE, a workaround is
offered to avoid hitting this issue against existing data.
The workaround is to enable UTF-8J decoder to be used in
place of the default UTF-8 decoder by setting the global
JCC property db2.jcc.alternateUTF8Encoding to 1. UTF-8J
decoder offers compatibility with pre-Java 8 UTF-8
conversion rules and may allow an application to work with
existing data without hitting this issue. (RTC 74367)
Problem Description :
COMPATIBILITY SETTING IS
SET FOR A PREVIOUS LEVEL. SQLCODE=-4743, SQLSTATE=56038,
DRIVER=X.XX.XXXX" in the following use case scenario
- you are using a new DB2 V11 functionality in your SQLJ
program,
- your have bounded the DB2 packages that are used at the data
server by the IBM® Data Server Driver for JDBC and SQLJ
-bindOptions "APPLCOMPAT(V10R1)"
- you are using -APPLCOMPAT V11R1 with the db2db2sqljcustomize
command
Recommendation
-APPLCOMPAT option is introduced with db2sqljcustomizer and
db2sqljbinder utility,
as part of this fix user can set V10R1 or V11R1 or whatever DB2
Z server supported option.
According to the value passed, the server side compatibility
mode will be enabled.. is this a new feature in SQLJ ::: YES
(RTC 69916) |
