| Some thoughts:
1. You need to establish how SQL*connect makes its connection to
DB2. Is it a VTAM application accessing DB2 via the call attachment,
or is SQL*connect a TSO application, or does it execute as a CICS
application ??? This is important to know since it will tell us
how seamless the integration really is. If SQL*connect runs as
a CICS application (which I doubt), the MVS host will need the CICS
attachment for DB2 (which comes from IBM).
2. You mentioned TSO for security purposes but should also check
to see if CICS and/or IMS applications will be needing to access
the VAX Oracle. There is a lot of difference between each of these
three approaches (TSO, IMS, CICS) and make no assumptions re: security
or integration. For example, IF SQL*connect runs as a TSO application
(batch or interactively), it is unlikely that a CICS application
can "seamlessly" (sp?) access the VAX Oracle database or vice versa.
3. Additional information we need to help analyze this solution:
a. Does Oracle run in a separate MVS region ?? Where does SQL*plus
run, SQL*net, SQL*connect run, Oracle kernel ???
b. Exactly (and I mean exactly) how does SQL*connect access
DB2. There are only four attachment facilities to
DB2 (CICS, IMS/DC, TSO, call). This is your #1 question.
c. Exactly how does the IBM application access VAX Oracle ?
SQL*net is NOT the answer since it is only a transport
layer, not an API. SQL*plus is not the answer since
SQL*plus stmts cannot be imbedded in an applicaiton
program.
4. Oracle cannot claim to have read/write capability to DB2 from
the VAX or from the IBM since this would require two-phase commit
and they DO NOT HAVE 2PC. Sure they may be able to write to DB2
through some obscure method but there is no recovery.
5. What does the Interlink box look like to the VAX?? to the IBM
?? If the interlink box requires MVS software (which I suspect
it does), that probably means it looks like a PU4 or PU5 vs a PU2.
This may mean some risk for future versions or MVS and/or Interlink
software coordination.
Based on what I know about Oracle's ability to connect to DB2, I'd
say they're getting ready to set up a consulting engagement to write
the code to match the requirements they've convinced the customer
to spec since their connection to DB2 is not nearly as clean as
VIDA.
|
|
Thanks for your reply Gerry. I've done some digging around in notes
and I came across this entry from Michael Booth.
<<< BISTRO::ETC:[NOTES$LIBRARY]RDB_VMS_COMPETITION.NOTE;1 >>>
-< Rdb/VMS against the world >-
================================================================================
Note 297.1 ORACLE & DB2 ?
1 of 4
BROKE::BOOTH "What am I?...An Oracle?" 22 lines 3-FEB-1989 16:06
-< Yes, but not Well >-
--------------------------------------------------------------------------------
Yes, in two ways.
Oracle tools can run on an IBM mainframe and make calls to a resident
DB2 database.
Oracle has a product called SQL*Connect that can be installed on
a mainframe. That product will allow an Oracle database on a VAX
to communicate with the IBM DB2 database via an SNA/Gateway.
Note that SQL*Connect will cost exactly 50% of the price of the
Oracle RDBMS on said mainframe. In addition, if the customer is
using MVS/XA (who isn't with DB2?), Oracle will tage him for another
service called "/XA Support". I think they will also have to but
SQL*Net to make the whole thing work.
Then once it's installed, the discovery is made that the only
communication is through Oracle's SQL*Plus interactive SQL. In other
words, none of the other Oracle tools have direct access to the
DB2 database. They must call pre-written SQL*Plus routines to get
to the IBM data.
---- Michael Booth
The bottom line seems to be that the link is not as quite as seamless
as they have suggested in that none of the tools have direct access
to DB2 , they need to call pre-written sql*plus routines to do so.
I dont think 2PC is an issue here as they are not updating oracle
and db2 in a single transaction.
I take your point ( in 5. ) about the interlink box and will look
into this a little further.
Charles
|
| > 4. Oracle cannot claim to have read/write capability to DB2 from
> the VAX or from the IBM since this would require two-phase commit
> and they DO NOT HAVE 2PC. Sure they may be able to write to DB2
> through some obscure method but there is no recovery.
No, you don't need 2PC. You only need 2PC to update more than one
database at a time. If what the customer is trying to do is have
SQL$FORMS on the VAX update a single DB2 database, then it would work
with fuil recovery, integrity, etc. (in theory, that is).
|
| I've come across the INTERLINK solution before. A friend at ORACLE
phoned to say that the easiest way for them to connect IBM PC's
to an IBM mainframe was via DECnet-DOS and INTERLINK!
There is a cautionary note in the solution though. INTERLINK use
to be DEC's good buddy before we had our high-speed channel attach
SNA solution. Since then, they have hopped into bed with IBM to
help provide IBM's access to the DECnet world including putting
DECnet under NETVIEW. While their earlier solutions were PDP and
�VAX based, I believe today they are looking at 9370 based products.
In addition, I think they are also working with IBM on providing
a DECnet 'Portal' product over SNA.
The bottome line! Be carefull with INTERLINK and look to see if
DEC now provides a product which can be used in its place! For more
information I would suggest trying some of the network conferences.
Paul
|