[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference ulysse::rdb_vms_competition

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

1087.0. "Rdb/VMS and Oracle/Sun integration..." by EPAVAX::CARLOTTI (Rick Carlotti, DTN 440-2194, Sales Support) Mon Feb 17 1992 16:04

My customer has the following integration challenge:  provide transparent 
database updates between an Rdb/VMS database and an Oracle/SUN database.

Here's the scenario:

This customer has a home grown Engineering database system on his VAX/VMS 
system.  They bought a turn-key system to provide storage/retrieval of their 
vast library of Engineering drawings.  Unfortunately, the turn-key system is 
written using Oracle on a Sun machine.  In order for an Engineer to make any 
changes to a drawing, they need to run transactions on both the VAX and Sun 
systems, which requires two separate logins.

What they would like to do (ultimately) is provide they same set of 
transactions on the VAX system and the Sun system, so that people who are 
usually logged into the VAX don't have to log into the Sun and vice-a-versa.

Updating the Rdb system from the Sun should not be too difficult once they 
have Rdb v4.1, since they will be able to make use of the new SQL Services 
for Sun.

However, updating the Oracle database from the VAX appears to be a more costly 
undertaking.  As I understand it, they have the option of buying a gateway 
from Oracle and probably some precompiler to allow a VMS application to access 
the Oracle database on the Sun via TCP/IP.  

Do they need the Oracle database on the VAX or can the gateway function 
without it?

How about writing some task-to-task code using RPC technology?  Is this 
feasible?

Is there a better way?  less expensive way?  other tools which can be used?

Any and all suggestions appreciated...

Thanks in advance,

Rick C
T.RTitleUserPersonal
Name
DateLines
1087.1SQL AccessBEAGLE::GODFRINDAlvin Toliver was hereTue Feb 18 1992 09:1830
>However, updating the Oracle database from the VAX appears to be a more costly 
>undertaking.  As I understand it, they have the option of buying a gateway 
>from Oracle and probably some precompiler to allow a VMS application to access 
>the Oracle database on the Sun via TCP/IP.  
>
>Do they need the Oracle database on the VAX or can the gateway function 
>without it?
>
>How about writing some task-to-task code using RPC technology?  Is this 
>feasible?

If the VAX application that updates the Oracle DB is 'stable' - that is it does
not issue free-format queries, but all the queries are well known in advance,
then I personally would favor writing an RPC-based application. Something that
would allow VAX applications to issue requests for fixed queries (identified
by some number), with the server end on the Sun executing the corresponding SQL
verbs. The actual queries would then be embedded on the Sun.

This can even lead to a more portable solution in the oong run. If the protocol
and the client/server functions aee well architected, you should be able to use
them to access other databases.

This is just my opinion. You would need to cost that and compare it with a 
tools-based solution (I am sure Oracle can provide one).

On re-reading what I just wrote, this is exactly what SQL-Access tries to
achieve. Check the BROKE::SQL_ACCESS conference for info and persons to
contact. 

/albert
1087.2ACA ServicesBROKE::THOMASAnne Thomas DTN 264-6094Wed Apr 08 1992 20:1613
    I think that what you'd really like to do here is integrate the 
    Rdb/VMS applications with the ORACLE/Sun applications, and not 
    necessarily simply access the database.  I'd suggest that you 
    take a look at ACA Services and try to integrate the applications.
    
    When the VMS application needs to access information for the Sun 
    system, ACA Services can invoke the Sun application.  For more 
    information about ACA Services, check out the VIA::ACA_SERVICES
    notes conference, or contact John (MRKTNG::) Clancy or Linda
    (IDE::) Storm.
    
    ACA Services is a phenominal integration tool.  If you don't know
    about it, you're definitely missing out.