This chapter describes the changes and corrected problems in this release. It includes the following sections:
The following table lists the versions of the components and utilities included with this product.
Product | Release Number |
---|---|
Oracle Transparent Gateway for DB2 | 10.2.0.2.0 |
Oracle Net | 10.2.0.2.0 |
This section lists the changes and enhancements to TG4DB2 by the release in which they were introduced.
The following changes and enhancements were incorporated in the 8.1.7 release:
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.
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.
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.
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.
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.
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
.
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.
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.
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.
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.
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.
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 GRANT
s), 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.
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).
The restrictions documented in this section are known to exist for the products included in the installation media. Also refer to Chapter 9, "Developing Applications" for information about limitations when developing applications.
DD Basic Tables and Views The owner of DD basic tables and views is OTGDB2. This cannot be changed.
Owner of DB2 Plan The qualifier for the DB2 plan must be the same as the owner for the ORACLE2PC
table in the DD SQL script, and it must be OTGDB2
.
Oracle SQL uses hexadecimal digits surrounded by single quotes to express literal values being compared or inserted into columns defined as RAW
. Currently, this is not converted to DB2 syntax (an X followed by quoted hexadecimal digits) when the SQL destination is the gateway. You must use bind variables to compare or insert into a DB2 server column defined with the FOR BIT DATA
option.
Gateway design requires that all host variables in a SQL operation be bound before performing a describe function. When using the Oracle Call Interface (OCI), all OCI bind calls for a given statement must be completed before an OCI describe call is made.
When you select RAW
data into character bind variables, the CHAR
column must be two times the size of the RAW
data. Selecting RAW
data into character bind variables causes implicit RAW to HEX conversion. If the character bind variable column is too small, then the SELECT
statement fails.
The SQLCHECK
option must be set to NONE
when precompiling programs with the Oracle Precompilers.
Although most differences between the Oracle database server SQL and DB2 SQL are handled by the gateway, the following restrictions exist:
Oracle ROWID
is not supported.
DB2 does not have a functional equivalent to Oracle ROWID
. Tools or applications depending on Oracle ROWID
are not supported.
UPDATE
and DELETE
with the WHERE CURRENT OF CURSOR
clause are not supported.
When these statements are used in precompiler and PL/SQL programs, they rely internally on the Oracle ROWID
function. Therefore, they are not supported.
Oracle bind variables become DB2 parameter markers.
Oracle bind variables become DB2 parameter markers when used with the gateway. Therefore, the bind variables are subject to the same restrictions as DB2 parameter markers. For example, the following statements are not allowed:
WHERE :x IS NULL WHERE :x = :y
For more information about DB2 parameter marker restrictions, refer to the IBM documents for your platform and operating system.
CONNECT BY
is not supported.
The Oracle-specific CONNECT BY
clause is not supported.
GTWY_IDLE_TIME
under the previous MPM architecture was replaced by OSDI IDLE_TIMEOUT
. See Section 5.4.6, "IDLE_TIMEOUT | ITIMEOUT".