2 Release Information

2.2.1 Changes and Enhancements in Release 8.1.7

The following changes and enhancements were incorporated in the 8.1.7 release:

Auto Registration   

Oracle Transparent Gateway for DB2 supports Heterogeneous Services auto registration.  This feature will significantly speed session initialization by storing class capabilities in the server data dictionary rather than uploading the capabilities and storing them in memory for each session.

DB2 Version 6.1 and 7.1 Stored Procedures

Oracle Transparent Gateway for DB2 now supports IBM's new procedure for running store procedures in DB2 version 6.1 and 7.1.

2.2.2 Changes and Enhancements in Release 9.2.0

The following changes and enhancements were incorporated in the 9.2.0 release:

Operating System Dependent Interface (OSDI)

Like Oracle Database 10g for z/OS, Version 9.2.0.1.1 of the Oracle Transparent Gateway for DB2 is based on Operating System Dependent Interface (OSDI), an execution environment for Oracle products on z/OS, which was introduced with Oracle8i, Release 3 (8.1.7).

OSDI represents a significant change from the old subsystems in terms of how Oracle products interact with the z/OS operating system.  These changes do not generally affect Oracle product behavior and the interfaces used by customer applications, but they do affect the installation, configuration, and administration of these products on z/OS.

If you are already an Oracle for z/OS customer with existing MPM or TNS subsystems, refer to Chapter 11, "Migration and Coexistence with Existing Gateways" for more information about differences between MPM and OSDI, and for migration and upgrade considerations.

TNSNAMES SID PARAMETER

Unlike previous MPM releases of the Oracle Transparent Gateway for DB2, the port number in the TNSNAMES entry is no longer sufficient to determine the destination of a connection request.  The NET listener can now listen on a single port for multiple z/OS destination address spaces.  The TNSNAMES entry must now include a SID= parameter.  This parameter value must match the SID(xxxx) value in the OSDI service definition.

SQL*Plus Describe Support

Using RDBMS 9.2 as integrating server, you can now use the SQL*Plus Describe command to describe DB2 objects.

DB2 (var)graphic to Oracle (var)char(2) Mapping Support

This release of Oracle Transparent Gateway for DB2 provides DB2 (var)graphic to Oracle (var)char(2) mapping support.  Refer to Appendix 12, "Globalization Support" for details.

Streams Heterogeneous Replication

Heterogeneous Replication is a new Oracle Database feature using Oracle gateway technology.  You need a minimum release of 9.2.0.2 database server release to take advantage of the feature.  Refer to "STREAMS Replication" on page 8-10, for details.

2.2.3 Changes and Enhancements in Release 10.1.0.2.0

The following changes and enhancements were incorporated in the 10.1.0.2.0 release:

RRSAF (Recoverable Resource Manager Services Attachment Facility)

All releases of Oracle Transparent Gateway for DB2 prior to 10g used the DB2 Call Attachment Facility (CAF) to access DB2. With this release, the DB2 RRSAF is now used for all DB2 access.

This is an improved interface and simplifies installation and security, eliminating the need to install DB2 logon exits in the DB2 systems to be accessed. RRSAF also opens up possibilities for new features in the Oracle Transparent Gateway for DB2.

If your installation was previously using RACF (or another security manager) to limit access to DB2 by DB2 session type (unlikely), you will need to change the security definitions to allow RRSAF access (instead of CAF).

DB2 Gateway-Specific DB2 Connect Exit Eliminated

With the switch to RRSAF, it is no longer necessary to modify the DB2 connect exit, DSN3@ATH.

If your installation previously modified Oracle's sample DB2 connect exit (from release 9.2 and earlier releases of the Oracle Transparent Gateway for DB2) and you want the same behavior in release 10g, you must make your own changes to the standard DB2 connect and DB2 sign-on exits (the sign-on exit is new for RRSAF). The DB2 sessions now come in as RRSAF instead of CAF types, so be sure to change the exits to look for this new type of connection. The Oracle Transparent Gateway for DB2 uses RRSAF SIGNON to connect to the DB2 system. You will need this information if you decide to modify the standard DB2 connect or DB2 sign-on exits.

Typically an installation would run their DB2 system with the standard DB2 connect and DB2 sign-on exits supplied by IBM and these would need no modification to run release 10g of the Oracle Transparent Gateway for DB2.

DB2 Gateway Logon Exit

The Oracle Transparent Gateway for DB2 has a new logon security exit that verifies the user ID and password supplied when a session starts. It also sets up the security environment so that an RRSAF SIGNON has the necessary information for a user to sign on to DB2.

The old exit (prior to release 10g) was supplied only in source form and was compiled as part of the installation process. This exit was for CAF only, and is obsolete.

The new exit is shipped as an executable (G4RRSAF) in AUTHLOAD. Most installations should be able to use this exit with no changes. If it is required to have the source code or if your installation needs to make site-specific changes to the exit, then it is shipped in source form in the SRCLIB PDS but is called G4SIGNON, and the JCL to assemble and link the file is also in SRCLIB. If you decide to change the exit, be certain to link it with another name (suck as G4SIGNON), do not replace G4RRSAF in AUTHLOAD.

Most installations should be able to run with the DB2 Gateway logon exit (G4RRSAF) supplied in executable form in AUTHLOAD.

DB2 Date Exit

An optional DB2 date exit (DSNXVDTX) that recognizes the Oracle date formats was shipped only in source form and compiled and linked as part of the installation process prior to release 10.1.0.2.0

This exit is now shipped as an executable, DSNXVDTX, in the AUTHLOAD. It can be copied to the load libraries of DB2 systems if you want to use this exit. Source is supplied in SRCLIB PDS as member DSNXVDTX along with JCL to assemble and link it. The source is provided, in case your site requires the source for any exits installed in your DB2 systems. Typically, this exit would not be modified, but the source is available in case you need site-specific changes to this exit (or you need to combine this exit with your own DB2 date exit).

Most sites should be able to use the DSNXVDTX DB2 date exit supplied in AUTHLOAD. There is normally no need to make any changes to this (optional) DB2 date exit if you decide to install it in a DB2 system.

User Defined Function Support

DB2 user-defined functions (UDFs) can now be called directly from Oracle SQL. Refer to the Oracle Database Heterogeneous Connectivity Administrator's Guide, for details.

Oracle TIMESTAMP Data Type Mapping

Optionally, DB2 TIMESTAMP columns can be returned as CHAR(26) columns (as in previously releases) or mapped to Oracle's TIMESTAMP data type. This feature is activated by the ORACLE_TIMESTAMP environment variable.

Currently, if the Oracle TIMESTAMP data type is chosen, the microseconds are lost.

New DB2 Data Types Supported

DB2's data types ROWID, BLOB, CLOB, and DBCLOB have partial support in this release.

DB2 ROWID columns appear to Oracle as RAW(40) columns.

BLOB, CLOB, and DBCLOB data types (types of long objects, or LOBs) have only partial support in this release. Each of these column types appears as a RAW(4) to Oracle, and the value returned is the DB2 LOB locator. This may be usable if passed back to a client-written DB2 stored procedure. Currently, the data in any type of LOB cannot be returned. This may be implemented in a future release.

OSDI IDLE_TIMEOUT

The new OSDI IDLE_TIMEOUT service parameter can be used to time out and automatically cancel any Oracle Transparent Gateway for DB2 session that has been idle for a specified amount of time.

2.2.4 Changes and Enhancements in Release 10.2.0.2.0

Full UNICODE Support

The DB2 Gateway now runs internally in UNICODE. All DB2 tables, EBCDIC, ASCII and UNICODE, using any DB2 character set, are supported.

Because the gateway now runs internally in UNICODE, HS_LANGUAGE can no longer be specified. HS_LANGUAGE is internally set to AL32UTF8 and cannot be changed.

Any DB2 table in any character set can now be accessed or updated.

The controlling factor in character set conversion now becomes the database character set of the Oracle integrating server. Ideally, the database character set of Oracle should be AL32UTF8. If you have an Oracle running in UTF8, you should convert it to AL32UTF8 (UTF8 is a subset of AL32UTF8). If you have an Oracle running in US7ASCII(the default Oracle database character set on ASCII platforms), you should convert it to AL32UTF8 (US7ASCII is also a subset of AL32UTF8).

All data retrieved from DB2 is converted from the DB2 character set directly to the database character set of the Oracle integrating server. If the Oracle server is running in AL32UTF8, all possible code points will be converted. If the Oracle server is running in any other character set (like WE8ISO8859P1), some code points may not have an equivalent and will be converted to the substitution character for that character set.

All SQL statements and input bind variable values for SQL statements will be provided to DB2 in UNICODE. This allows any code point in any character set to be sent to DB2. If the Oracle integrating server isn't running in AL32UTF8, then the SQL statement and bind variables will be converted from the Oracle server's character set to AL32UTF8. For this reason, it is highly recommended to run the Oracle server in AL32UTF8.

All passthrough SQL statements will be sent to DB2 in UNICODE. If there are differences in how a SQL statement must be coded for UNICODE (like for DB2 GRAPHIC literals), the UNICODE form must be used.

This new UNICODE feature allows for the maximum accessibility to DB2 data. Every code point in every DB2 character set can now be retrieved from DB2 or provided as input to DB2. The only limiting factor is the database character set of the Oracle integrating server.

LOB Support

BLOB, CLOB and DBCLOB data types (types of long objects, or LOBs) are supported in this release. Where only a RAW(4) LOB locator was returned previously (see new features for 10.1.0.2.0 above), in this release, the actual data values of the LOB are returned. BLOB datatypes appear as LONG RAW, and, CLOB and DBCLOB datatypes appear as LONG types. The entire value is retrieved on a SELECT, just like a regular LONG RAW or LONG column.

SAVEPOINT and ROLLBACK TO SAVEPOINT Support

SAVEPOINT and ROLLBACK TO SAVEPOINT are now supported.

Improved Data Dictionary Translations

The Data Dictionary Translations, which simulate several Oracle tables (like ALL_TABLES and ALL_TAB_COLUMNS) retrieving data from the DB2 catalog have been significantly enhanced. The improvements provide a closer simulation to the Oracle equivalent data dictionary tables. The performance and accuracy of the translations has also been significantly improved.

Support is now provided for the DB2 7.1 and DB2 8.1 catalogs (which are different). The longer names in DB2 8.1 are now returned in the data dictionary translations and some new values available in DB2 8.1 are returned as well.

External security data dictionary translations are also provided.

If you use DB2's external security (an exit is called which typically makes RACF calls to check for DB2 object security instead of DB2 checking for GRANTs), then new views are available for you to use.

The problem with DB2's external security is that the GRANT information in the DB2 catalog is not used. There are no DB2 tables which contain GRANT information, all of the access information is in an external security system (typically RACF). Consequently, the data dictionary translations cannot check the DB2 catalog to see if a user has access to an object.

The alternative external security views simply return all objects rather than just the objects a user has access to. For example, the standard security view for ALL_TABLES returns just the tables that a user has been granted access to through DB2 GRANT commands. However, the external security views simply return every table in the DB2 catalog for ALL_TABLES (since there is no grant information in the DB2 catalog to check against).

With the external security views, a user will be able to retrieve the definition of all of the objects in the DB2 catalog. However, the user will only be able to access the objects that the external security exit allows access to.

Oracle Timestamp Data Type Mapping

Mapping of DB2 TIMESTAMP columns to Oracle's TIMESTAMP data type was introduced in 10.1.0.2.0 (see new features for that release above).

Previously, the DB2 TIMESTAMP's microsecond's were lost. In this release, the full timestamp, including the microseconds, are included in the Oracle TIMESTAMP value.

DB2 Gateway Logon Exit Enhanced

Several enhancements were made to the DB2 Gateway logon exit. The SAF call was enhanced to improve performance of the security checking call and a change was made to suppress the console log message that appeared every time the security check was done.

NCHAR Support Dropped

The NCHAR data type is no longer supported. All DB2 GRAPHIC, VARGRAPHIC and DBCLOB datatypes are converted to their CHAR equivalents (CHAR, VARCHAR and LONG respectively).