CLI, .NET and JCC Enhancements with download information for 10.5 Fix Pack 6 Special Build

News

Abstract

This document contains the details of CLI, .NET & JCC driver enhancements for Client only release and image download links for special build 35031.

Content

$ db2 "<some sql statement>" SQL0969N There is no message text corresponding to SQL error "-4742" in the message file on this workstation. The error was returned from module "DSNXOTL " with original tokens "reason-code". SQLSTATE=42704

With the new -y option, we can get complete message text for -4742 error code from server as below:

$ db2 -y "<some sql statement>" SQL4742N [SERVER] THE STATEMENT CANNOT BE EXECUTED BY DB2 OR IN THE ACCELERATOR (REASON reason-code). SQLSTATE=42704

The [SERVER] text just after SQLCODE in above message text indicates that the printed message text is from connected database server and not from the local message file.

2. Ability to specify registry for trusted context

CLI driver has the attributes SQL_ATTR_TRUSTED_CONTEXT_USERID and SQL_ATTR_USER_REGISTRY_NAME to specify the userid and registry name to be used in the trusted connection for switching the user.

CLI allows the applications to set the registry name through SQL_ATTR_USER_REGISTRY_NAME attribute only before establishing the connection, but where as SQL_ATTR_TRUSTED_CONTEXT_USERID can be set any time after establishing the connection.

Now the SQLSetEnvAttr() and SQLSetConnectAttr() APIs have been enhanced to accept the setting of SQL_ATTR_USER_REGISTRY_NAME attribute after connection and after statement allocation also. This will enable the user to specify the registry name along with end userid for switching to different user in trusted connection. Specifying the registry name along with userid enables the z/OS server to map the registry name and userid to RACF id using identity mapping feature of z/OS to switch the trusted context based connection.

Switching the user in the trusted context based connection with z/OS identity mapping feature using SQL_ATTR_USER_REGISTRY_NAME is applicable only against the DB2 for z/OS servers.

3. Serviceability enhancements - client diagnostics duplicate timeout period

For a specific event, where there could be many threads, the same SQLCODE will be reported across all the threads on the occurrence of an issue. For example, during a failover scenario, the error code SQL30108N will be seen across all the threads connected to the same failed member and from serviceability point of view, the same diagnostic information will be captured into the serviceability log file for each thread. This results in duplicate information getting captured into the log file & this also can result in the log file getting wrapped up quickly and the information related to the first occurrence could be lost.

Now, changes are provided such that the diagnostic information for any SQLCODE is captured for the first thread alone where the issue is seen & the information logging for the same SQLCODE is skipped for the other threads until a specific time period elapses.

Also, the following additional information is captured in the serviceability log:
• The server & client product versions
• Complete SQLCA structure
• For the SQL30108N & SQL20542N error codes, more diagnostic information is logged.

In order to specify the time period during which the diagnostic information should not be captured for a SQLCODE, the IBM data server driver configuration keyword db2dumpSQLCodesInterval (in db2dsdriver.cfg) has been introduced. The timing will start after the log information is captured for the first occurrence of the SQLCODE. Once the set time elapses, the log information for the same SQLCODE will be once again captured on the occurrence of the issue. The value set in the new keyword is applicable for all the SQLCODES specified in the 'db2dumpSQLCodes' keyword.
The value set in the 'db2dumpSQLCodesInterval' keyword is applicable only if there is a valid value in the 'db2dumpdataSQLCodes' keyword.
The 'db2dumpSQLCodesInterval' keyword can be specified only in the global parameters section of the db2dsdriver.cfg file.

Usage scenario:

Suppose, 'db2dumpSQLCodes' is set to 30108,20542,1224 &
'db2dumpSQLCodesInterval' is set to 20

At time X, SQL30108N occurs. Now, the log information for the first SQL30108N occurrence is logged. Then, the log for other SQL30108N occurrences is not logged until time exceeds X + 20 seconds.
Mean while at time X + 1 second, SQL20542N occurs. Now, the log information for the first SQL20542N occurrence is logged. Then the log for other SQL20542N occurrences is not logged until time exceeds X + 1 + 20 seconds.
It should be noted that only the seconds value will be considered for any computation & the fractional time will be ignored.

4. Extended Insight (EI) copy files from bulk deploy with dsdriver install

Infosphere Optim Data Tools Runtime Client (DTRC) is used to monitor and configure ODBC/CLI, .NET and Java applications with the DB2 tools like Infosphere Optim Performance Manager ( OPM ) and IBM Data Server Manager (DSM).

To avoid the scenario where customers have to install the DTRC client manually on all the machines where the application is running, DTRC has provided a bulk deploy image which is a zip file containing the library files for each of the platforms that can be unzipped to a network drive visible to all the machines running the application.

But one has to copy those platform dependent DTRC client library files from the network drive to the dsdriver installation location manually.
Now, a mechanism has been provided to automatically copy the platform specific DTRC client library files from the network drive into the installed ds driver location during dsdriver installation.

For LU, 'installdsdriver' script will support a new option called '-installdtrc' which takes the location of the bulk deploy root directory as the input. With this new option 'installdsdriver' script will first determine on what platform it is running and then it will copy all the contents of the java directory to dsdriver installation directory where jcc(db2jcc4.jar) libraries are present and non java library contents from the respective platform directory to dsdriver installation directory where cli libraries(libdb2.so) are present.

The installdsdriver script will display a message to the standard output whether the files are successfully copied or not. The log file will be also be updated with the same information.

If the DTRC bulk deploy library files already exists, installDSDriver with the new option will overwrite the existing DTRC library files.
This option will also be supported during the upgrade of the installed dsdriver location. During the upgrade, the user can use the new option -installdtrc along with the -upgrade option to the copy or overwrite the DTRC bulk deploy library files.

For windows, the option of copying the DTRC bulk deploy library files during installation will be provided only with the silent installation. The response file used for silent installation will support a new keyword called EI_BULK_DEPLOY_ROOT_DIRECTORY.
This keyword will take the path of the bulk deploy root directory as input. When provided with the path, installer will copy the java libraries and the other files from java directory to dsdriver installation directory where jcc(db2jcc4.jar) libraries are present and all non java library contents from the respective platform directory to dsdriver installation directory where cli libraries ( db2app.dll ) are present.

EI_BULK_DEPLOY_ROOT_DIRECTORY = **location of the network drive.

Also, the db2dsdriver.cfg.sample file which contains OPM entries in the global parameter section has been updated to accommodate both OPM and OCM entries.

<parameters>
<parameter name="GlobalParam" value="Value"/>

</parameters>

5. Microsoft App-V support for IBM Data Server Driver Package

Microsoft Application Virtualization (MS App-V) platform allows applications to be deployed ("streamed") in real-time to any client from a virtual application server. It removes the need for traditional local installation of the applications, although a standalone deployment method is also supported. With a streaming-based implementation, the App-V client needs to be installed on the client machines and application data that is stored on the virtual application server is installed (streamed) to the client cache on demand when it is first used, or pre-installed in a local cache. The App-V stack isolates the execution environment so that an application does not make changes directly to the underlying operating system's file system and/or registry, but rather contained in an application-specific "bubble"/environment. App-V applications are also isolated from each other, so that different versions of the same application can be run under App-V concurrently so that mutually exclusive applications can co-exist on the same system.

Microsoft App-V thus allows centralized installation and management of deployed applications.

The App-V client presents the user with a neat, locally-installed application experience for virtualized applications. Access to start the virtualized application appears to be identical to the locally installed application, as extensions for the application are integrated into the user's desktop shell by the App-V client.

The Microsoft Application Virtualization (App-V) Sequencer is a component of the App-V suite used to package applications to be deployed to systems using the App-V Client. Properly sequencing applications is critical to a successful App-V implementation. As such, it is important to follow recommended practices and steps needed to sequence and deploy IBM Data Server Driver and be aware of the different options when sequencing. The proper configuration and sequencing of IBM Data Server Driver is imperative to successful running of virtual application developed for Data Server Driver package for App-V.
Completing the installation of virtual application often requires performing several manual steps like troubleshooting App-V package that are not part of the application installation process to ensure that applications will function properly when launched on a client.

Now App-V will be supported for IBM Data Server Driver. Necessary steps to create App-V IBM Data Server Driver image using Microsoft App-V sequencer and steps to install, deploy and test the IBM Data Server Driver App-V image using App-V client is provided.

6. IBM i timestamp precision

Prior to V7.2, DB2 for i supported 6 digits precision for fractional part of seconds in the timestamp format. From V7.2 onwards, DB2 for i has extended the precision for fractional part of seconds to contain variable length precision of up to 12 digits(in the range 0-12). The default remains the same i.e. 6 digits.
The timestamp format is :
Default : Timestamp(6) = YYYY-MM-DD-hh-mm-ss.ffffff
Extended precision: Timestamp(0-12)=YYYY-MM-DD-hh-mm-ss.ffffffffffff

Now, CLI supports the extended timestamp precision of 12 digits supported from DB2 for i V7.2 onwards.

SQL_C_TYPE_TIMESTAMP_EXT can be used in following 3 APIs in CLI.
SQLBindcol(), SQLGetData() & SQLBindParameter().

7. CLI Load attribute for load replace resetdictionaryonly

Earlier, application could pass the REPLACE options to CLI LOAD utility through piActionString or piLongActionString member of db2LoadStruct type variable using SQL_ATTR_LOAD_INFO statement attribute. However, many CLI applications do not use the SQL_ATTR_LOAD_INFO statement attribute to pass pre-populated db2LoadStruct to CLI, but uses other load related statement attributes to set CLI LOAD options. For such applications, there is no statement attribute available to provide the options KEEPDICTIONARY, RESETDICTIONARY and RESETDICTIONARYONLY for LOAD REPLACE operation.

Now, a new CLI statement attribute has been provided that application can set to specify KEEPDICTIONARY, RESETDICTIONARY and RESETDICTIONARYONLY options for LOAD REPLACE operation.

The new statements attribute SQL_ATTR_LOAD_REPLACE_OPTION will accept following values:
• SQL_LOAD_KEEPDICTIONARY or 1 – For KEEPDICTIONARY option.
• SQL_LOAD_RESETDICTIONARY or 2– For RESETDICTIONARY option.
• SQL_LOAD_RESETDICTIONARYONLY or 3 – For RESETDICTIONARYONLY option.
• SQL_LOAD_REPLACE_DEFAULT or 0 – To clear the above set option.In this case, CLI LOAD REPLACE will behave as no option is set for this statement attribute. The LOAD REPLACE operation will show default behavior. For row-organized tables, KEEPDICTIONARY is the default value and for column-organized tables, RESETDICTIONARY is the default value used internally by db2Load() API.

Value set for this new statement attribute SQL_ATTR_LOAD_REPLACE_OPTION will be effective only if the existing statement attribute SQL_ATTR_USE_LOAD_API is set using SQL_USE_LOAD_REPLACE value. Otherwise, the value set for this new statement attribute SQL_ATTR_LOAD_REPLACE_OPTION will get ignored.

In case of multiple calls for SQL_ATTR_LOAD_REPLACE_OPTION, the value last set will be used.

Application can call SQLGetStmtAttr()API to retrieve the value set for this new statement attribute.

8. access to CA to return DBMS indicator

SQL Communication Area(SQLCA) is a standard structure that contains a pre-defined collection of variables that are updated for every SQL statement execution by IBM DB2. Currently there are various informative fields that could be utilized as potential indicators for deciding the flow in an application or for generating optimized coding solutions by application developers, vendors, users etc. One such indicator is sqlwarn[7] field populated by server for specific database flavor, for example, BigSQL, DashDb, SQLDB. For determining Big Insights BigSQL version of LUW, 10^th token of sqlerrmc can be used along with sqlwarn[7]. SQLCA can also be used to determine if DB2 for z/OS is running in new feature mode or compatibility mode. likewise, there are numerous ways in which server provides indications in SQLCA w.r.t to their compatibility, database flavor etc.

DB2 CLI provides its users with 2 diagIdentifiers viz SQL_DIAG_ERRMC and SQL_DIAG_SQLSTATE that could be used to retrieve sqlerrmc and sqlstate fields of the SQLCA respectively. However, currently these identifiers are restricted by the record number i.e values are defined for these identifiers only in error scenarios as they belong to the record field of the diagnostic data structure. Hence, for successful connections, no values are defined in these fields.

When ever a connection to one of the IBM DB2 databases/servers viz BigSQL, DashDb, SQLDB, DB2 for z/OS, DB2 for i is established successfully, the SQLCA would be populated by server with necessary and required fields that would indicate the status of connection, type and version of the server connected to, type of the database service etc.
However, it is expected to return database flavor indicator present in the SQLCA for DashDB database from CLI. This indicator would mainly be used by applications to make a dynamic decision on what functionality users wish to choose depending on the server connected to.
Since, different flavors of databases choose to populate different SQLCA variables for different indications, it would be appropriate to return full SQLCA to applications via an API Interface to provide full range support for connection SQLCA information from CLI.

Currently, CLI has SQLGetDiagField() API that returns the current value of a field of a diagnostic data structure, associated with a specific handle, that contains error, warning, and status information. It supplies users with a wide range of Diag Identifiers each of which provides the information as documented here:

http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.apdv.cli.doc/doc/r0000608.html

To the existing DiagIdentifiers list, a new identifier/attribute would be added viz: SQL_DIAG_SQLCA which when specified, full connection SQLCA would be returned to the application.

This new identifier belongs to the header fields of the Diagnostic data structure. Hence, the record number passed to the API is ignored. This identifier can only be used on a connection handle after the connection is attempted via one of the CLI supported connection APIs.

The SQLCA on the connection handle can be retrieved for either a successful or a failed connection.
If an attempt is made to retrieve the SQLCA on a connection handle for a failed connection, SQLCA related to the error is returned.

The SQLCA for the connection can be retrieved at any point of time after the connection is established successfully but before the connection is disconnected. Any attempt to retrieve the SQLCA after the connection is disconnected would return a default SQLCA. The ODBC recommended way to extract the diagnostic information for all other cases remains unchanged. i.e. SQLGetDiagRec() with various identifiers supported today other than SQL_DIAG_SQLCA and SQLGetDiagField() APIs can be used retrieve the diagnostic information in all such cases.

9. Connect to specific member bypassing client affinity

When client affinities is in use, connections are established based on the affinity list of alternate servers instead of the host name and port number that are specified through the connection string by the application. For example, if an application specifies that a connection should be made to server1, but the IBM Data Server Driver configuration file specifies that servers should be tried in the order (server2, server3, server1), the initial connection is made to server2 instead of server1.

Earlier, with SQLDriverConnect/SQLBrowseConnect api, the connection will not necessarily be opened with the member specified in the connection string, even if the member is fully qualified with hostname and port. Instead, the connection will be routed according to the client affinity lists if the provided member connection information matches the information in database or DSN section of the db2dsdriver.cfg file.

Instead of establishing the connection to a server specified in the list of alternate servers configured in the IBM Data Server Driver configuration file, it is expected to use the connection information specified for establishing the connection (.i.e. the connection should happen to the database, hostname & port specified in the connection string). Thus the <acr> section configured parameters should not come into effect
However, if only the DSN name is mentioned in the connection string, the behavior should remain unchanged and the connection information should continue to be picked up from the affinity list of the corresponding database in db2dsdriver.cfg configuration file. Thus the <acr> section configured parameters should come into effect.

Basically, customers would like to connect to a specific member as mentioned in their connection string and monitor the statistics for the member that they are connected to. In this case they would not want the connection to happen to any member other than what they have specified in connection string.

CLI has provided a new connection attribute SQL_ATTR_IGNORE_SERVER_LIST. Upon setting this attribute, reading of the <wlb> and <acr> section in db2dsdriver.cfg file will be avoided, both WLB & ACR feature will be disabled. Connection would always be made against the server as specified by database, hostname, port information in the connection string.

Setting SQL_ATTR_IGNORE_SERVER_LIST to true will disable automatic client reroute feature. DB2 client will ignore the server list returned by server as well. If the new attribute is set, even if the <wlb> and <acr> section is not configured in db2dsdriver.cfg, both WLB & ACR feature will be disabled. Connection will happen to the hostname specified in the connection string

.NET enhancements

1. LDAP settings in global area of dsdriver.cfg

With this release, .NET provider and tooling will allow reading various LDAP parameters defined in db2dsdriver.cfg file under <ldapserver> section within <configuration> main section. Please see below a sample db2dsdriver.cfg file with LDAP configurations:

<configuration> <dsncollection> <dsn alias="alias1" name="name1" host="server1.net1.com" port="50001"/> </dsncollection> <databases> <database name="name1" host="server1.net1.com" port="50001"> <parameter name="CurrentSchema" value="OWNER1"/> ... </database> </databases> <ldapserver> <parameter name="EnableLDAP" value="YES"/> <parameter name="LDAPServerHost" value="myhost.lab.ibm.com"/> <parameter name="ClientProvider" value=”IBM”/> <parameter name="BaseDN" value="O=IBM"/> <parameter name="UserID" value="root"/> <parameter name="Password" value="itv23"/> </ldapserver> </configuration>

Restrictions

I. Only a single <ldapserver> entry is allowed in the db2dsdriver.cfg file. If there is more than one <ldapserver> section, then the parameters defined in the last <ldapserver> section will take effect. db2cli validate, however, will complain in case of more than one <ldapserver> section.

2. Ability to specify registry for trusted context

With this release, DB2 .Net applications can additionally send the user registry name as a part of end user distributed identity in the connection string while switching to a trusted connection. Using a trusted connection, DB2 for z/OS detects the registry name and then passes on the distributed identity to RACF to be mapped against a RACF user ID.

A new connection string keyword “TrustedContextUserRegistryName” alias “TCURN” is created .This keyword can also specified as part of connection string builder.
The “TCURN” attribute should be used only during switching the user ID on a trusted connection.
This connection string attribute is supported only on DB2 for zOS database server.

Note: This keyword is not supported as a part of db2dsdriver.cfg file .

3. EntityFramework 6.1 GA Feature (Connection Resiliency)

DB2 .Net driver supports EF 6.1 Connection Resiliency feature.

Connection Resiliency refers to the ability for EF to automatically retry any commands that fail due to these connection breaks.

For more information about the feature , please refer the below link :
http://msdn.microsoft.com/en-us/data/dn456835
https://entityframework.codeplex.com/wikipage?title=Connection%20Resiliency%20Spec
http://msdn.microsoft.com/en-US/data/dn307226

4. Serviceability enhancements

To improve diagnostics collection for intermittent issues, the following new features are added.
• A mechanism to capture all the required diagnostic information on the first occurrence of the issue.
• Capture the information in such a way that the disk space doesn't get full.

On the occurrence of a specific event ( SQLCODE ), the following is logged into a file to provide better diagnostic information for a given connection:

• Configuration parameters that have been explicitly set (not the default ones).
• Sysplex configuration information.
• Sysplex member statistics
• Sysplex group statistics.
• Connection details like connection handle, state of the connection.
• Client information properties that have been set.

Two rotating log files per process are being generated. Each log file size will be limited to 1 MB. Once one file reaches a size of 1 MB, the data will be dumped afresh in the other log file & so on. The file name will have the format as db2dumpdata_<pid>.<index>.log where 'pid' represents the process-id & 'index' is a number greater than or equal to 0.

The log files are placed in a directory named 'clientrecords'. The 'clientrecords' directory is placed in the path specified in the 'diagpath' configuration parameter. See the following link for complete details.
http://pic.dhe.ibm.com/infocenter/db2luw/v10r5/topic/com.ibm.db2.luw.admin.config.doc/doc/r0000299.html

The 'clientrecords' folder might have many log files. The cleaning up of unnecessary/unused log files needs to be taken care of manually.

Two new keywords Db2DumpSQLCodes, Db2DumpSQLCodesInterval are introduced in .Net applications via connection string and data server driver configuration keyword

a) db2dumpSQLCodes connection string / db2dsdriver.cfg keyword :

Specifies whether diagnostic logs are gathered when specified SQLCODEs are encountered in a connection to the DB2® for z/OS® server.

Property value

'OFF'
No diagnostic information is logged. The default value is 'OFF'.

'DEFAULT'
A special value that is equivalent to setting the following absolute SQLCODE values.
30108 for the SQL30108N error
20542 for the SQL20542N error
1224 for the SQL1224N error

Absolute SQLCODE values
Absolute SQLCODE values that are separated by comma. Only the absolute SQLCODE values can be specified. The following statement specify SQL30108N and SQL20542N for the db2dumpSQLCodes keyword.

Db2dumpSQLCodes = “30108,20542”;

Remarks
You can enable a mechanism to capture diagnostic information on the first occurrence of an SQL error event in the connection to the DB2 for z/OS server with the db2dumpSQLCodes keyword. The db2dumpSQLCodes keyword setting takes effect only after the application is restarted.

b) Db2DumpSQLCodesInterval connection string / db2dsdriver.cfg keyword :

Db2DumpSQLCodesInterval keyword can be used in order to specify the time period during which the diagnostic information should not be captured for a SQLCODE.

The timing will start after the log information is captured for the first occurrence of the SQLCODE. Once the set time elapses, the log information for the same SQLCODE will be once again be captured on the occurrence of the issue. The value set in the new keyword is applicable for all the SQLCODES specified in the 'db2dumpSQLCodes' keyword.
The value set in the 'db2dumpSQLCodesInterval' keyword is applicable only if there is a valid value in the 'db2dumpdataSQLCodes' keyword.
The 'db2dumpSQLCodesInterval' keyword can be specified only in the global parameters section of the db2dsdriver.cfg file.

Usage scenario:

Suppose, 'db2dumpSQLCodes' is set to 30108,20542,1224 &
'db2dumpSQLCodesInterval' is set to 20

At time X, SQL30108N occurs. Now, the log information for the first SQL30108N occurrence is logged. Then the log for other SQL30108N occurrences is not logged until time exceeds X + 20 seconds.
Mean while at time X + 1 second, SQL20542N occurs. Now, the log information for the first SQL20542N occurrence is logged. Then the log for other SQL20542N occurrences is not logged until time exceeds X + 1 + 20 seconds.
It should be noted that only the seconds value will be considered for any computation & the fractional time will be ignored.

5.Timestamp precision for IBM i

With DB2 for i V7R2 and later, timestamps have increased precision, having a range of 0-12. IBM Data Server provider for .NET and Visual studio Addins now supports DB2Timestamp representing timestamp datatype with increased precision in the range of 0 to 12 when connected to DB2 for i V7R2 or later.

6. Support regex in SQL for IBM i

DB2 for i V7R1 and later supports regular expressions in SQL which includes
support for REGEXP_LIKE predicate and four different scalar functions namely,
REGEXP_COUNT, REGEXP_INSTR, REGEXP_REPLACE and REGEXP_SUBSTR.

This release will support executing SQL statements using Visual studio Addins with regular expressions using Script Designer, Command Console when connected to DB2 for i V7R1 or
later

Also, in Script Designer and Command Console window, SQL keyword highlighting (color code would be changed to blue) would be added for these new SQL keywords namely, REGEXP_LIKE, REGEXP_COUNT, REGEXP_INSTR, REGEXP_REPLACE and
REGEXP_SUBSTR.

7. Visual Studio 2015 Support

With this release 'IBM Database Add-ins for Visual studio'(VSAI)' supports Visual Studio 2015(VS2015) .

The install program would check existence of Visual Studio 2015 and DB2 .NET Provider, and will add necessary registry entries to make 'IBM Database Add-ins for Visual studio' work with Visual studio 2015.

8. Access to CA to return DBMS indicator

With this release, when ever a connection is made to the database, server will return database flavor indicator .This indicator can be used by applications to make a dynamic decision on what functionality users wish to choose depending on the server connected to.

Since, different flavors of databases choose to populate different SQLCA variables, we would return full SQLCA to applications via an API Interface to provide full range support for SQLCA information.

.Net API information :

public string getsqlerrmc(bool format)

This method has a parameter of boolean type. If the parameter is false, sqlerrmc contains delimiters and is provided as is. If the parameter is true, then this method returns a string with delimiter removed.

A complete example of how the CA information can be accessed through the new interface in .NET provider is provided below.

DB2Connection m_conn1=new DB2Connection(“database=sample”);
m_conn1.Open();
sqlca strdiag = m_conn1.GetCAInfo();

int sqlabcVal=strdiag.sqlcabc; //Directly access the integer field.

If the char array is needed directly, use the following field:
char[] sqlerrp = strdiag.sqlerrp ;

Incase the complete value is needed
string strsqlerrp = strdiag.getsqlerrp ;

For sqlerrmc value, it can be accessed either as raw char array data
char[] sqlerrmc = strdiag.sqlerrmc;

or as a raw string data
string strsqlerrmc = strdiag.getsqlerrmc(false);

or as formatted string
string strsqlerrmcFormatted = strdiag.getsqlerrmc(true);
…..
….
m_conn1.Close();

IBM Data Server Driver for JDBC and SQLJ enhancements(JCC)

1. Compatibility with Java 8 Runtime Environment

The IBM Data Server Driver for JDBC and SQLJ is now compatible with Java 8 Runtime Environments. Refer IBM Data Server Driver for JDBC and SQLJ APARs IT12454 and IT12461 shipped with this release for known Java 8 compatibility issues that have been fixed.

Java 8 has stricter UTF-8 decoding rules. The following global property has been introduced, which can potentially help applications running under an IBM JRE that face issues due to this:

db2.jcc.alternateUTF8Encoding

Specifies whether the IBM Data Server Driver for JDBC and SQLJ running under IBM JRE Version 8 and above, uses UTF8J implementation in place of UTF8 when working with UTF8 data. Use this property only if you hit UTF8 character decoding errors due to the stricter UTF8 implementation in Java 8.

Valid values are:
0
Use the standard UTF8 implementation provided by the JRE for UTF8 data

1
If running under IBM JRE, use UTF8J implementation for UTF8 data

The default value is 0.

2. OSGi compliant bundling of driver jars

The driver jars have limited OSGi support. The driver jars shipped with this release can be deployed in an OSGi environment. However, full fledged OSGi compliance shall be provided in future.

3. Support for PKI Card based client authentication has been enhanced

In earlier releases of the driver, selection of an appropriate certificate for client authentication could fail when multiple certificates in a Windows Certificate Store carried a blank or duplicate alias.

The support for client authentication has been enhanced in this release to prevent such a malformed keystore from causing a client authentication failure. The driver
automatically detects if the client application uses a keystore of type Windows-MY which contains certificate entries with duplicate or blank aliases. In such a case the driver takes corrective steps to ensure that the right certificate from the keystore is selected for client authentication. No user intervention or configuration change on the part of the client application is needed.

4. db2sqljcustomize SQLJ Profile Customizer has been enhanced

You can distinguish which language a package has been created with using the genDBRM hostLangJAVA clause.

A new option "-hostLangJAVA" has been introduced for the -genDBRM command of the SQLJ Profile customizer

When -genDBRM is specified on db2sqljcustomize, the -hostLangJAVA option specifies that the db2sqljcustomize process should create DBRM files that identify their host language as 'J'. When these DBRMs are bound into DB2 packages, the corresponding HOSTLANG column in the SYSIBM.SYSPACKAGE table is set to 'J'. This identifies packages that were generated with the Java language. This option is only available for DB2 on ZOS v11 and above.

5. Serviceability enhancements

Following serviceability enhancements have been made:

• Circular tracing for JCC Serviceability dumps. Event data is now dumped into two rotating files for each JVM. Files reach a size of maximum 2MB before being recycled.

• You can configure any SQL codes on which to create serviceability dumps. With this, integer constants related to logging diagnostic information for error codes in JCC have been discontinued.

When the db2.jcc.diagLevelExceptionCode global configuration property is set to -1 and the db2.jcc.dumpDiagLevel global configuration property is set to 1, the IBM Data Server Driver for JDBC and SQLJ collects the diagnostic information

The diagnostic data is written to a file named jccDump_<timestamp>_<random-no>_i.log, where i =0 or 1, in the directory that is specified by global configuration property db2.jcc.outputDirectory. This file can reach up to 2MB. When an application writes its first trace record, the driver creates a file with i = 0. The driver then writes trace data to the file. When the size of the file reaches 2MB, the driver renames the file such that index i is replaced from 0 to 1. The driver continues this cycle until the application completes. Each dump entry inside the file will include the timestamp, jvm-name, thread ID, data source ID, and connection ID details, so you may locate the source of exception.

Important:

• The maximum file size that a file can take is not strictly 2MB . It may exceed 2 MB so that the last dump entry is fully logged into a single file for easier readability.
• Bringing down a JVM by killing the Java process can create .lck files on the file system. These .lck files must be deleted manually.

The db2.jcc.diagLevelExceptionCode global configuration property can be set to the error and warning codes for which diagnostic information needs to be captured. When configuring this property, negative signs in SQL warnings are optional. SQL codes can be suffixed by 'n' for negative SQL codes and 'p' for positive SQL Codes.

For example, to collect diagnostic information for -204 , -30108, the properties file would look like one of the following three:

• db2.jcc.diagLevelExceptionCode=-204,30108n
• db2.jcc.diagLevelExceptionCode=204,30108
• db2.jcc.diagLevelExceptionCode=-204,30108,4499n

SQL Warnings must be configured with a positive sign or suffix with 'p' For example, to collect diagnostic information for SQL warning +100 , SQL error code -30108 and SQL warning +222, the properties file should have an entry that looks like one of the following

• db2.jcc.diagLevelExceptionCode=+100,-30108,222p
• db2.jcc.diagLevelExceptionCode=100p,30108,+222

6. useCachedCursor property has been deprecated

The useCachedCursor property has been deprecated in the new driver. You will obtain optimal performance when the property is left unconfigured. That is, when it has no explicit value provided by application. If you would like the older driver behavior, explicitly set the property to “true” or “false”.

[{"Product":{"code":"SSSNY3","label":"IBM Data Server Client Packages"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"--","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"10.5","Edition":"","Line of Business":{"code":"","label":""}}]

Tips

CLI, .NET and JCC Enhancements with download information for 10.5 Fix Pack 6 Special Build - 35031

News

Abstract

Content

Historical Number

Was this topic helpful?

Document Information

UID

Share your feedback

Need support?