home clear 64x64
en blue 200x116 de orange 200x116 info letter User
suche 36x36
Neueste VersionenFixList
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Haben Sie Probleme? - Kontaktieren Sie uns.
Kostenlos registrieren anmeldung-x26
Kontaktformular kontakt-x26

DB2 - Problembeschreibung

Problem IC78953 Status: Geschlossen

DOCUMENTATION OF CHANGES IN IBM DATA SERVER DRIVER FOR JDBC AND SQLJ
VERSION 3.64.XX/4.14.XX FOR DB2 LUW V9.7 FIXPACK 6

Produkt:
DB2 CONNECT / DB2CONNCT / 970 - DB2
Problembeschreibung:
Type-4 Connectivity: When enableSysplexWLB is true and 
db2.jcc.maxTransportObjects is not set JCC driver might 
create excessive number of transport objects after a 
successful failover..The problem has been fixed. 
(wsdbu01016787, wsdbu01016635, wsdbu01015961) 
 
Type-4 Connectivity: When enableSysplexWLB is true 
and db2.jcc.maxTransportObjects is not set 
and DVIPA is used, JCC driver might create excessive 
numbers of transport objects when some or all 
members come back up after all being  down. 
The problem has been fixed. (wsdbu01017179) 
 
Type-4 Connectivity: In a workload balancing 
environment, JCC Driver has made a performance 
improvement by not retrying the connectivity to the 
member that is known unavailable during the auto failover. 
(wsdbu01031011) 
 
Type-4 Connectivity: In a workload balancing 
environment, with two DB2 zOs data sharing groups 
defined if after the first successful  transaction to 
the primary group both the groups go down then the number 
of failover attempts during the subsequent transaction 
should not exceed the default value of 5 for the property 
maxRetriesForClientReroute. The problem has been fixed. 
(wsdbu01031245) 
 
Type-4 Connectivity: In a workload balancing 
environment, the value returned by API 
numberOfRequestsBlockedPoolMax() 
and.totalTimeBlocked() from the object that is 
based on the com.ibm.db2.jcc.DB2PoolMonitor class 
might not be correct.  (wsdbu01000053) 
 
Type-4 Connectivity: In a workload balancing 
environment against pureScale server, JCC driver was 
able to open its first connection successfully to the 
primary member and have received the server list of more 
than one member. Even then the subsequent connections 
failed to connect to any other members in the server list 
if the primary member went down. (wsdbu01032594) 
 
Type-4 Connectivity: In a workload balancing 
environment, when there are many threads competing for 
getting the connection to the DB2 server where there are 
not enough transport objects in the pool, and if the wait 
time that is specified in the maxTransportObjectWaitTime 
property is too short, it is possible that driver may 
create a hang situation where most of the threads are in 
the waiting state. (wsdbu01037165) 
 
Type-4 XA Connectivity: In a workload balancing 
environment if a XA transaction fails at XA Commit with 
XAER_RMFAIL then that transport (socket) should be 
closed. JCC driver was not closing that transport and 
subsequent use of that transport was resulting in 
SQLCODE30090 (-30090). (wsdbu01009695) 
 
All connectivity types: JCC driver did not the trace 
the thread id and statement ID when printing the 
SystemMonitor:stop entry in the trace. (wsdbu01025219) 
 
All connectivity types: When a SQL contains FETCH first 
N ROWS clause and also the PreparedStatement.setMaxRows(m) 
is used in an application then if m < n, the dynamic 
execution of the prepared statement returns 
n results, and the static execution of the same prepared 
statement returns m rows. The dynamic and static case 
should be the same.The problem has been fixed. 
(wsdbu01031486) 
 
All connectivity types: JCC driver was incorrectly 
printing the reason code information along with the 
-30108 error message even though it did not make 
sense when performing failover in a load balancing 
environment. (wsdbu01016188) 
 
Type-4 connectivity:JCC driver throws SQLException 
(-4499) SQL4499 on next getConnection() if the 
application changes the target server within a 
DB2SimpleDataSource instance. (wsdbu01013713) 
 
All Connectivity: The DatabaseMetadata.getCatalog() 
JDBC API does not return the current database/location 
to which it is connected to. Also the 
DatabaseMetadata.getCatalogTerm() API has to be 
changed to reflect this change in behavior. The 
getCatalogTerm() API will now return "location" for 
z/OS and "database" for LUW. (wsdbu01035789) 
 
Type-4 Connectivity: The driver was 
throwing DDM object not supported 
exception (-4499) SQLN4499 while 
attempting to bind driver packages 
against DB2 LUW V10.1 server. 
(wsdbu01039748) 
 
Type-4 Connectivity: The driver incorrectly raises 
the connectionErrorOccurred() events on the 
pooledConnection's ConnectionEventListener 
during the failover attempts driver internally 
makes in a HADR or workload balancing environment 
even though no external connection errors are 
reported. The problem has been fixed now. 
(wsdbu01038029) 
 
LUW: Type-2 and Type-4/Z: type 4 Connectivity only: 
JCC enables a new mechanism for the auto-discovery 
of the OPM Monitor server address for the benefit 
of applications that fail to configure a controller 
URL properly during the installation at the client. 
This mechanism can be used to enable OPM Extended 
Insight monitoring even when an OPM controller 
URL is not configured at the client. If a client 
does not have an OPM controller URL configured, 
then an auto-discovered monitor server address 
and port obtained from a JCC driver stored 
procedure call will be used. The driver will 
be invoked by OPM/EI to make this stored 
procedure call only once and only for the 
first connection of a data source during the 
life of the JVM process. If OPM/EI runtime 
jar (pdq.jar) is not present on classpath, 
then this feature is not used and stored 
procedure call is not made. 
(wsdbu01024465, wsdbu01028664, wsdbu01035086) 
 
All connectivity type: Previously, JCC caches 
trial license, that is, if the customer has trial 
license, after calling the license stored procedure, 
we cache the license information so in the next 7 
days, using JCC driver won't call the license 
procedure any more. After the change, we don't 
put the license information in the cache any more 
for trial license, so every time using JCC driver, 
the stored procedure will be called. For regular 
license, we still cache the license information 
as usual.(wsdbu01032279) 
 
T4 connectivity type: previously, when Abnormal 
End Unit of Work Condition happens and JCC trace 
is on, Exception with message "DSS chained with same 
id at end of same id chain parse. ERRORCODE=-4499" 
may happen.  The problem has been fixed. 
(wsdbu01037806) 
 
Sqlj: When using V97FP5 JCC3/JCC4 to customize and bind the 
sqlj profile, then using V97FP5 JCC4/JCC3 to run the sqlj 
application, the driver will throw java.sql.SQLException: 
profile xxxxx_SJProfile0 not found. The problem is fixed. 
(wsdbu01016254) 
 
SQLJ ALL  Connectivity Types: 
When the option -pkgversion AUTO  is used, the 
SQLJ Customizer now generates a version 
String in the following format 
YYYY-MM-DD-HH.MM.SS.nnnnnn 
This version String is recorded in the serialized Profile 
and is used in the subsequent Bind. 
(wsdbu01030687) 
 
SQLJ ALL  Connectivity Types: 
In a Websphere environment an SQLJ application 
may hit an  NullPointerException thrown 
from the SQLJ Runtime with the method 
getCurrentTime() in the stack trace. 
Tracing code in the SQLJ Runtime was 
not thread-safe.This problem has been fixed. 
(wsdbu01041605 ) 
 
SQLJ ALL  Connectivity Types: 
Incorrect code was generated for an 
SQL SELECT INTO statement using a common 
table expression specified with the 
'WITH' keyword. 
SQLJ Translator issued the  Warning 
'Value returned by SQL query is not assigned to a variable.' 
The SQLJ  runtime threw the  following SQLException 
when the program was run 
'Method executeUpdate cannot be used for query.' 
The SQLJ translator was fixed to generate correct 
code. After applying the APAR re-translate 
the sqlj program, Customize/Bind again. 
(wsdbu01043533) 
 
Type-4 Connectivity: The driver uses JDK 
InetAddress.getHostName() 
and InetAddress.getCanonicalHostName() methods to figure out 
the host name of an IP Address.  This can perform terrible if 
the DSN lookup is not setup in the user environment. Driver has 
provided a new driver level global property to disable the use 
of these methods. The new property name is 
db2.jcc.enableInetAddressGetHostName which can be set in the 
driver's Configuration Property file or via a JVM property. 
The default is set to True which means the driver will continue 
to use InetAddress.getHostName() and 
InetAddress.getCanonicalHostName() methods to figure out 
the host name of an IP Address.  If the property is set to 
False, driver will stop calling these methods. (wsdbu01023484) 
 
Type-2 z/OS: SQLCODE501(-501) is returned on 
PreparedStatement.executeBatch if the statement 
was created from Connection.prepareStatement 
(insertSqlText, Statement.RETURN_GENERATED_KEYS) 
and the target table's identity column was not 
declared as GENERATED ALWAYS AS IDENTITY. 
(wsdbu01031986) 
 
Type-2 z/OS: The driver changes the column sqltypes to 
nullable when requesting DB2 z/OS v10 to fetch the data using 
block fetch. Now it will use the column nullable attributes 
which are defined when performing block fetch for diagnostic 
purpose. (wsdbu01029064) 
 
The length field for GDA should have value as 0xFF and not 0x20. 
 
But the server should try to assemble the N-GDA and CPT into one 
 
struct. The problem is the last CPT entry it has a wrong value 
indicating 20 fields ((20 + 1) * 3 = 0x3F) but it should have 
only 7 fields. (9 in N-GDA 4 in CPT holding 20 fields each that 
leaves us with 7 fields). This problem has been fixed. 
(wsdbu01023598) 
 
All connectivity type: Serialized SQLException object 
using one DB2 Universal Driver and DB2 for Linux, Unix, and 
Windows version was not compatible to other versions. 
Reading a serialized object with a version of driver which is 
different from that is used during serialization  may result 
in SQLException . This problem is fixed. (wsdbu01003673)
Problem-Zusammenfassung:
**************************************************************** 
* USERS AFFECTED:                                              * 
* Users of the IBM Data Server Driver for JDBC and SQLJ        * 
**************************************************************** 
* PROBLEM DESCRIPTION:                                         * 
* See Error Description                                        * 
**************************************************************** 
* RECOMMENDATION:                                              * 
* Upgrade to DB2 LUW V9.7 Fixpack 6                            * 
****************************************************************
Local-Fix:
verfügbare FixPacks:
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows

Lösung
Problems fixed in DB2 LUW V9.7 Fixpack 6
Workaround
keiner bekannt / siehe Local-Fix
Weitere Daten
Datum - Problem gemeldet    :
Datum - Problem geschlossen :
Datum - der letzten Änderung:
27.09.2011
04.06.2012
04.06.2012
Problem behoben ab folgender Versionen (IBM BugInfos)
9.7.FP6
Problem behoben lt. FixList in der Version
9.7.0.6 FixList