| ORACLE usually recommends that customers use an Interlink gateway
rather than one of our gateways. But there's no reason why you
couldn't use either the ST or the CT gateway. ORACLE provides
interoperability with DB2 using their networking product, SQL*Net,
and their DB2 access product, SQL*Connect for DB2. SQL*Net provides
a transparency layer for ORACLE products. It can layer on most any
kind of network, including DECnet, TCP/IP, and SNA. ORACLE systems
can speak to other ORACLE systems pretty much transparently using
SQL*Net. A VMS-based ORACLE system can also speak to an MVS-based
SQL*Connect system, which will translate requests into DB2.
SQL*Connect can be accessed from SQL*Plus, ORACLE's end-user query
tool, but it cannot be accessed from SQL*Forms, ORACLE's 4GL
environment. SQL*Connect can be used to update a DB2 database from
the VAX, but in order to do so, the DB2 database must first be
duplicated in ORACLE on MVS (yes, that's right -- you must install
ORACLE on MVS in order to update DB2). The updates are first made
to the ORACLE/MVS system, then the updates are transferred to DB2.
ORACLE recommends the Interlink gateway because SQL*Connect is a
slow product, and they feel it is necessary to use a channel-attach
gateway in order to provide acceptable performance. You'd probably
be wise to recommend the CT rather than the ST.
(By chance, would your customer be interested in looking at Rdb?
VIDA for DB2 provides a much more comprehensive and efficient
solution.)
|