PI47282: NEW RELEASE OF THE IBM DB2 DRIVER FOR JDBC AND SQLJ (RELEASE 4.19) PROVIDING VARIOUS ENHANCEHMENT

Obtain the fix for this APAR.

APAR status

• Closed as program error.

Error description

• NEW RELEASE OF THE IBM DB2 DRIVER FOR JDBC AND SQLJ (RELEASE
  4.19) PROVIDING VARIOUS ENHANCEHMENT
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: All Users of the IBM Data                    *
  *                 Server Driver for JDBC and SQLJ              *
  ****************************************************************
  * PROBLEM DESCRIPTION: IBM Data Sever Driver for JDBC and      *
  *                      SQLJ version 4.19.56 is provided by     *
  *                      this APAR ( JCCV41956 )                 *
  *                                                              *
  *                      This APAR is applicable to IBM Data     *
  *                      Sever Driver for JDBC and SQLJ          *
  *                      for DB2 z/OS V11, DB2 z/OS V10 and      *
  *                      DB2 z/OS V9( JCCZOSDB2V11,              *
  *                      JCCZOSDB2V10, JCCZOSDB2V9 )             *
  *                                                              *
  *                      This APAR delivers a new release (4.19) *
  *                      of the IBM Data Server Driver for JDBC  *
  *                      and SQLJ providing an accumulation of   *
  *                      defect fixes and enhancements.          *
  *                                                              *
  *                      Individual items are documented in the  *
  *                      APAR summary section that follows.      *
  *                                                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  JCC sub-category keywords:
      JCCCOMMON, JCCT2ZOS, JCCT4, JCCT4XA, JCCSQLJ
  
  The following changes are delivered in this APAR:
  _______________________________________________________________
  All Connectivities: In a WebSphere Application Server
  environment, a JNDI reference to a DataSource is passed to the
  driver's hydrateFromReference() API to generate the DataSource
  using the properties included in the JNDI reference. The
  java.lang.NumberFormatException error may be observed during
  this processing. This occurs due to a mismatch in the expected
  data type of the useCachedCursor DataSource property value.
  This problem has been fixed. (RTC 79494)
  _______________________________________________________________
  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, RTC 84266)
  _______________________________________________________________
  All Connectivities: Support a new value
  DB2BaseDataSource.CONNECTION_CLOSE_WITH_COMMIT (3) for
  "connectionCloseWithInFlightTransaction" driver property.
  This value allows an application to indicate that if a
  connection is closed in the middle of a transaction and
  autoCommit is disabled, then any uncommitted operations should
  be implicitly committed before closing the connection. No
  exception is raised to the application.
  This issue has been fixed.(RTC 47251)
  _______________________________________________________________
  All Connectivities: JCC driver started supporting JDK8 runtime
  environment. (RTC 57429, RTC 74367, RTC 59939)
  _______________________________________________________________
  T2zos Connectivity: When a gobal transaction is active, an
  Unsupported Feature error message appears in the log file. This
  occurs when the driver internally invokes setAutoCommit() while
  a global transaction is active. The setAutoCommit() API
  expectedly returns the error and driver absorbs it with no side
  effects. However, a log message indicating the setAutocommit()
  failure is produced. This has been fixed by ensuring driver
  never internally invokes setAutoCommit() when a global
  transaction is active. (RTC 80297)
  _______________________________________________________________
  T2zos Connectivity: When fetch occurs with LBF on, in certain
  rare conditions the server may end up writing data to a memory
  location specified by a driver pointer that is deallocated.
  This causes a memory overlay and results in an ABEND at a later
  time. This issue has been fixed. (RTC 77509)
  _______________________________________________________________
  T2zos Connectivity: The driver does not apply timeout on
  a resultset.next() API even when the enableTimeoutOnCursor
  property is set to true. This issue has been fixed. (RTC 77090)
  _______________________________________________________________
  Type-4 Connectivity: The PreparedStatement.setObject( )
  API does not support seamless failover in case a
  client-reroute eligible error such as a communication
  error occurs during it's invocation. The support for
  seamless failover to the setObject( ) API has been added.
  This issue has been fixed. (RTC 82450)
  _______________________________________________________________
  Type-4 Connectivity: When transport pooling is in use,
  unexpected errors like a NullPointerException on a
  ResultSet.next() may occur with the following stacktrace:
  java.lang.NullPointerException
   at com.ibm.db2.jcc.t4.hb.a
   at com.ibm.db2.jcc.t4.h.a
   at com.ibm.db2.jcc.t4.h.writeScrollableFetch_
   at com.ibm.db2.jcc.am.ResultSet.flowGetRowset
   at com.ibm.db2.jcc.am.ResultSet.getNextRowset
   at com.ibm.db2.jcc.am.ResultSet.nextX
   at com.ibm.db2.jcc.am.ResultSet.next
  This occurs because the transport is getting switched
  incorrectly. The traces from the driver indicate switching
  of the transport in the middle of a running query. This problem
  has been fixed. (RTC 31496)
  _______________________________________________________________
  Type-4 Connectivity: When a Properties object specified on
  a DriverManager API is constructed with defaults in this
  manner:
    Properties defaults = new Properties();
    defaults.put(<key1>, <key1 value>);
    Properties props = new Properties(defaults);
    props.put(<key2>, <key2 value>);
    DriverManager.getConnection ( url, props);
  then, it is observed that the defaults specified do not get
  used in setting the corresponding connection properties.
  This issue has been fixed. (RTC 52718)
  _______________________________________________________________
  Type-4 Connectivity: If a connection is attempted to a
  PureScale HADR cluster when it is in standby mode, the
  driver receives an error wih SQLCODE1776(-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 has been observed that even when the cached server
  list exists, the driver does not check it and
  returns a connection failure SQLException with
  SQLCODE1776(-1776) to the application.
  This issue has been fixed. (RTC 67068)
  _______________________________________________________________
  Type-4 Connectivity: In some cases it is observed that
  DB2Connection.isDBValid() or Connection.isValid() APIs
  return true but the connection throws a SQLException with
  ERRORCODE4499(-4499) when an operation is attempted immediately
  following the API call. The error indicates that the
  underlying connection socket was closed. This occurs due
  to a race condition when the timeout specified on the
  isDBValid() or isValid() API is very close to the actual
  time it takes for the driver to complete a connection
  validity check. When facing this issue, one workaround is to
  increase the timeout specified on the isDBValid() or isValid()
  API call to eliminate chances of the race condition occurring.
  This issue has been fixed. (RTC 63572)
  _______________________________________________________________
  Type-4 Connectivity: A NullPointerException may be thrown
  by the driver in case there is a problem in accessing the
  jccdiag.log. One scenario where this issue is seen
  involves the driver performing a server side license check
  and receiving an SQLCODE805(-805) from the DB2 server in
  response. The driver tries to log this server side license
  check failure to the jccdiag.log. The driver fails to obtain a
  valid OutputStream to the jccdiag.log file and generates a
  NullPointerException.
  This issue has been fixed.(RTC 47917)
  _______________________________________________________________
  Type-4 Connectivity: If a workload alters the value of special
  register CURRENT_CLIENT_ACCTNG across transactions, then in
  certain cases, it may not get set correctly and may carry an
  empty value. This issue has been fixed.(RTC 57429)
  _______________________________________________________________
  Type-4 Connectivity:When CURRENT PACKAGE PATH is changed
  dynamically using a collection ID not bound on the server,
  NullPointerException error message may follow with an
  SQLCODE805(-805), during execution of a prepare statement.
  This issue has been fixed. (RTC 31878)
  _______________________________________________________________
  Type-4 Connectivity: The loginTimeout and memberConnectTimeout
  properties are used to control the maximum time in seconds to
  wait for a connection to a data source. However, they do not
  take effect with Client affinities during client reroute.
  This issue has been fixed. (RTC 55313)
  _______________________________________________________________
  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
  to execute 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 INTERRUPT_PROCESSING_MODE_CLOSE_SOCKET (2)
  interrupt mode does not
  generate an interrupt on the DB2 for z/OS server. With
  this APAR, this problem is fixed by now defaulting the
  interrupt processing mode to
  INTERRUPT_PROCESSING_MODE_STATEMENT_CANCEL (1) if a
  connection is through a DB2 Connect Gateway. (RTC 68037)
  _______________________________________________________________
  SQLJ and All Connectivities: SQLJ trace generator has been
  modified to improve overall performance of SQLJ.
  (RTC 74421)
  __________________________________________________________
  SQLJ and All Connectivities: When an SQLJ application repeatedly
  executes SELECT INTO statement in a loop with the setMaxRows
  defined and the number of loop iterations are higher than the
  setMaxRows value, it results SQLCODE100(100) which is
  no row found error.
  This issue has been fixed.(RTC 64893)
  _______________________________________________________________
  SQLJ and All Connectivities:  SQLJ DB2SQLJCustomize may return
  ERRORCODE4743(-4743) when a new DB2 V11 SQLJ application uses
  db2 v11 features. This issue has been fixed. (RTC 74920)
  _______________________________________________________________
  SQLJ and All Connectivities: The db2sqljcustomize and
  db2sqljbind commands are changed to generate the consistency
  token values in an increasing timestamp order. (RTC 48550)
  _______________________________________________________________
  SQLJ and All Connectivities: When an application passed an
  invalid timestamp to create a timestamp with timezone, the
  driver used to check the validity of the timestamp and throw an
  internal error. With the fix, the driver passes the invalid
  timestamp directly to the server and SQLN181 (SQLCODE181) will
  be issued by the server, and the driver will externalize the
  SQLCODE error to the application. (RTC 56904)
  _______________________________________________________________
  SQLJ and All Connectivities: DB2 Connect Property
  sqljAvoidTimeStampConversion can be used to suspend timestamp
  Gregorian calendar validation of and conversion of timestamp
  values in a SQLJ application. (RTC 53453)
  _______________________________________________________________
  SQLJ and All Connectivities: The APPLCOMPAT option is
  introduced with the db2sqljcustomiz and db2sqljbind commands to
  allow user to set V10R1 or V11R1 or any other DB2 Z/OS server
  supported option. According to the value passed, the server
  side compatibility mode will be enabled.
  (RTC 69916)
  

Problem conclusion

• The items described in the APAR Problem
  Summary have been resolved as noted in
  the summary and included in this APAR.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

  UI35890 UI35891 UI35892

Modules/Macros

•    DSNAJJC1 DSNAJJC2 DSNAJ3CC DSNAJ3CE DSNAJ3CF
  DSNAJ3CM DSNAJ3C0 DSNAJ3C1 DSNAJ3C2 DSNAJ3C3 DSNAJ3C4 DSNAJ3C5
  DSNAJ3C6 DSNAJ3C7 DSNAJ3C9 DSNAJ6CC DSNAJ6CE DSNAJ6CF DSNAJ6CM
  DSNAJ6C0 DSNAJ6C1 DSNAJ6C2 DSNAJ6C3 DSNAJ6C4 DSNAJ6C5 DSNAJ6C6
  DSNAJ6C7 DSNAJ6C9
  

Fix information

• Fixed component name

  DB2 ODBC/JDBC/S

• Fixed component ID

  5740XYR02

Applicable component levels

• RA12 PSY UI35890

     UP16/03/10 P F603

• RB12 PSY UI35891

     UP16/03/10 P F603

• R912 PSY UI35892

     UP16/03/10 P F603

Fix is available

• Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.