| Title: | DEC Rdb against the World |
| Moderator: | HERON::GODFRIND |
| Created: | Fri Jun 12 1987 |
| Last Modified: | Thu Feb 23 1995 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 1348 |
| Total number of notes: | 5438 |
I am working with a customer who is evaluating Rdb and ORACLE. One of
the customer's requirements is read and write access to DB2. I have
explained that we can offer transparent read with VIDA and that we can
provide write access with APPC LU 6.2, 3270 DSPI, etc.
I explained what I thought was accurate about ORACLE based on what I
have read in this and the VIDA notes files, which is:
1) Read access is provided with SQL$Connect through SQL$PLUS
only; SQL*FORMS applications can not access DB2.
2) For read or write access to DB2 the ORACLE database engine
must be on the MVS system.
3) Write access is provided by first updating the ORACLE database
on MVS and then updating the DB2 database.
The customer says that ORACLE has said the following:
1) Read and write access can be provided to DB2 without the ORACLE
database being on the MVS system.
2) They attended a show where ORACLE demoed access to DB2 from
within an application (they weren't sure whether application
was created with SQL$FORMS). I am not sure the customer was
sure of what he saw. When I asked what mainframe ORACLE
connected to for the demo, he said he wasn't sure they
connected to any that it could have been a simulation. Is
there any reason that they couldn't use a 3GL and do LU 6.2
to provide the application access?
Is anyone out there sure that ORACLE's current versions require the
ORACLE database to be installed on the mainframe to provide DB2 access.
The customer said they have discussed this with ORACLE and "ORACLE
explained it all to them". He said that ORACLE says they ordinarily
discount SQL$Connect by 50% if you purcase the ORACLE database for
MVS. If the customer does not want to purchase the database for MVS
then they have to pay full price for SQL$Connect. So ORACLE is making
it look like packaging SQL$Connect with the ORACLE database is just
marketing and not a technical requirement.
If the facts are that the database has to be on MVS, can anyone provide
me with anything that I can pass on to the customer which would cause
him to question ORACLE further? Any suggestions on strategy are also
welcomed.
Sandy Clark @CEO
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1009.1 | Try some drawings | KCBBQ::DUNCAN | Gerry Duncan @KCO 452-3445 | Sun Oct 20 1991 03:59 | 71 |
Re: writing to DB2 from the VAX (with Rdb), you could use the LU6.2 version of DECmessageQ communicate with the IBM host and thus DB2. Oracle has announced SQL*net V2 which may account for some new functionality. The trade rags have briefly discussed this new release ... but no meat yet. As I understand it, in order to access (for read or write) DB2, your IBM program would link to and call the DB2 "call attach". I suppose it is possible that the IBM host version of SQL*connect could interact with DB2's call attach. If this is true, then the Oracle engine would not be required on the IBM host. But, the more I think about it, it seems to me that it probably doesn't matter all that much since, somewhere along the line, SOME piece of Oracle code (either the RDBMS or the SQL*connect) must use one of DB2's "attach" facilites. (Others include the IMS attach, CICS attach, and, I believe one for TSO). Perhaps some of the VIDA developers can help. If you're trying to win the solution away from Oracle, an approach you could try would be to draw two block charts show all our layers required to 1) read from DB2 and 2) to write to DB2. I've had the "write to DB2" requirement before but its usually turned out to be an over night or "in a few minutes" is good enough scenario. Chart 1 - read from DB2(you draw the boxes) VAX application Rdb Dispatch VIDA for DB2 (client) LU6.2 | DECnet/SNA gateway | VTAM CICS VIDA for DB2 (server) CICS attach for DB2 DB2 Chart 2 - write/update to DB2 VAX application (same as in Chart 1 or detached "writer" process) DECmessageQ LU6.2 | DECnet/SNA gateway | VTAM DECmessageQ (server) IBM application (custom developed by Digital EIS) DB2 While this is not as transparent, I believe it is much more straightforward than Oracle's numerous layers of SQL*net, SQL*connect, SQL*this and SQL*that. I suggest you have more opportunities to tweet performance in the approach above. To pin Oracle down will be difficult. Unless your customer can draw for you these layers and point to specific interface points in the Oracle solution, you can probably assume they really don't know either. And maybe if you help him construct one for Oralce (with or without Oracle's help), he'll begin to see problem areas with Oracle's approach. Good luck ! | |||||
| 1009.2 | If you want to stop all DB2 activity, go ahead | IJSAPL::OLTHOF | Henny Olthof @UTO 838-2021 | Wed Nov 27 1991 16:15 | 7 |
In order to write to the DB2 database on MVS, jou must not only have an
Oracle RDBMS installed (plus many SQL*%@!(*#E$(*@# products), but
when writing to DB2 from that intermediate Oracle database on MVS,
all other activities on that target DB2 database must be stopped!
Have Fun,
Henny Olthof, TP-DB Netherlands
| |||||