Conference orarep::nomahs::dbintegrator_public_public

1109.0. "Problem accessing RMS through DBI gtwy from Oracle" by ORAREP::ZPOVC::CSNAQS () Thu Dec 26 1996 21:06

    Hi,
      I would like some advice on the following problem
    
    The customer want to see our solution to read/write access to RMS
    (VAX/VMS). 
    Eventhough we have Oracle Gtw for RMS but it is only providing read
    access. 
    So we propose the RDB Transparent Gtw to RMS (aka DBI Gtw to RMS) and
    RDB  
    Transparent Gtw to Oracle7. 
    The RDB TGW to RMS is going to provide access to the existing RMS data  
    while the RDB TGW to O7 will use as the physical database and also the
    db 
    for the new applications. 
    The products and version are as follow : 
     
    (i) 
    DEC UNIX 3.2C 
    Oracle7 RDBMS (7.1.6) 
    RDB TGW to Oracle7 V3.1 
    DBI V3.1 
     
    (ii) 
    VMS/VAX 5.1 
    RMS datasource 
    RDB TGW to RMS V3.1 
    DBI V3.1 
     
    (iii) 
    Wins95 
    Developer/2000 1.2 
    ODBC for RDB 2.0.1 
     
    We have setup the Oracle7, RDB TGW to Oracle and DBI (SQL/Service) on
    the DEC 
    UNIX. And manage to create a phyical database on Oracle7, created a
    link
    table 
    (via the RDB TGW) accessing the oracle table.  
    This is tested with D2K going to 
    the RDB ODBC -> DBI(DEC UNIX) -> RDB TGW Oracle7(DEC UNIX) -> Oracle
    table. 
     
    The creation of this link table and physical database are done at the
    DEC
    UNIX 
    host. 
     
    The customer have setup the RDB TGW RMS (VMS) and also RDB TGW RDB
    (VMS) 
    (physical database) 
    at their site and manage to remotely access RMS (via TGW RMS) from the
    RDB 
    (VMS) host. 
     
    Now we want to access the RMS data through the similar setup from the
    DEC
    UNIX 
     : 
    the RDB ODBC -> DBI(DEC UNIX) -> DBI(VMS) -> RDB TGW RMS (VMS) -> RMS
    data. 
    So we need to setup the link table for RMS data, and this is how I
    create my 
    link : 
     
    SQL> CREATE LINK DBIRMS TO 'filename 
    NCOMV3::/type=nsds/pathname=sysops:[dbi]main.cdo/ 
         user=combstan/pass=xxxxx/remote'; 
     
    next create the link table : 
     
    SQL> CREATE TABLE user_sys LINK TO user_sys USING DBIRMS; 
     
    ERROR : 
     
    %RDB-F-SYS-REQUEST 
     DBI-E-ATTLNKERR 
     RDB-F-IO-ERROR 
     COSI-F-CONNECFAIL, connect over network timed-out or failed 
     
    When I remotely attach the RDB (VMS) physical database through the ISQL
    (DEC 
    UNIX), 
    similar error (COSI-F-CONNECFAIL) also appears. 
     
    But I have no problem attaching the RDB (VMS) from the Develop/2000
    (Wins95) 
    via (RDB ODBC), 
    similar attach string is used as attaching the RDB via ISQL (DEC UNIX)  
     
    Now we suspect either a bug or some network config error at the DBI or 
    SQL/Services on 
    the DEC UNIX. 
     
     
    Regards

 
Please allow me to ask a few questions & then suggest some ideas. 
 
In the configuration you describe it appears that you have installed DBI on 
Unix and VMS (the same place where the RMS files are).  Is this true? 
 
Also, is TCPIP being used everywhere in the configuration?  Or is DECnet 
installed somewhere? 
 
Regarding read/write access to RMS, has anyone mentioned the 
advantages/disadvantages to using RMS Journaling in this scenario? 

You mentioned RDB TWG RDB...what is this?  There is no Rdb Transparent Gateway
to Rdb.  There is a Oracle Transparent Gateway to Rdb.  Or do you imply that 
this is DBI using a Rdb catalog?
 
If read/write access to RMS is really necessary from a Unix system running DBI 
then I would suggest defining a DBI link on Unix to go to DBI on VMS.  On the 
VMS system, in DBI, have a link to RMS and import the RMS table into DBI on 
VMS.  Then from DBI on Unix import the DBI/RMS table from VMS/DBI. 
 
Why do all this?  Because the NSDS engine does not understand the USER USING 
or /SQL_USER and /SQL_PASSWORD syntax.  All of the Unix users will be accessing 
RMS files as the user RDB$REMOTE.  This problem will be fixed in the next 
version of the RMS gateway which will use the NREL engine in place of NSDS.   
 
On the DBI link on Unix use /SQL_USER and /SQL_PASS with /TYPE=DBI to get to 
DBI on VMS.  Then on VMS in DBI define a regular link to RMS using /TYPE=NSDS. 
 
Because DBI will be using the Rdb remote protocols I would check access using 
interactive SQL from Unix to get to something on VMS.  Can you create a simple 
PERSONEL database on VMS and then access it from interactive SQL on Unix?  
This removes the DBI and NSDS layers while checking the Rdb remote protocols 
and network.  Once you know that this works then try going like this: 
 
Unix DBI -> VMS DBI -> RMS 
 
On the Unix DBI only have links to VMS DBI.  On VMS DBI have the links with 
/type=NSDS. 
 
I would also very seriously consider RMS Journaling on the VMS machine for 
transaction integrity and locking considerations for the read write access to
RMS. 
 
Hope that this helps and let me know how you make out, 
Don Green

    
    
>Why do all this?  Because the NSDS engine does not understand the USER USING 
>or /SQL_USER and /SQL_PASSWORD syntax.  All of the Unix users will be accessing
>RMS files as the user RDB$REMOTE.  This problem will be fixed in the next 
>version of the RMS gateway which will use the NREL engine in place of NSDS.   
    
    Actually it doesn't look like it will be fixed in the nrel gateway that
    will be released soon.  We will try to get this fix into the V8
    timeframe however.
    
    Sorry for any confusion.
    
    Dan