Conference orarep::nomahs::dbintegrator_public_public

1084.0. "DB2 & Sybase client on a WNT server" by ORAREP::GIDDAY::REINHOLD (Skippy) Thu Aug 01 1996 01:26

    Gidday,
    	
    	The following problem is from Peter King (a regular poster in this 
    conference) whom has now left DIGITAL and become the customer.
    	Fortunately I cannot add anything to their problem, other than
    what do you think?
    
    						Cheers,
    							Dave
    
    -----------------------------------------------------------------------
    
        
    *********************************************************************
    *Caveat: I do not - in all honesty - expect a resolution from the
    DBI folk. However, I see no harm in exploring all avenues and someone
    may have seen this type of problem before in a different configuration
    or be able to give really useful pointers.  
    *********************************************************************
    
    We are trying to extract data from a DB2 database using a Sybase
    client on a WNT server. The client connects to a DBI database with the
    appropriate link and tables defined to access the DB2 database. The
    Sybase products used for the Sybase-DBI connection are Omni SQL Server
    for VMS/AXP (Omni) and OmniSQL Access Module for Rdb (RDBAM).
    
    Configurations
    --------------
    
    There are two configurations to contend with. One works, the other
    doesn't - under certain circumstances. The configurations are:
    
    - Production
    
    Sybase NT connection to Omni-RDBAM running on Alpha 2100 Server(COPY)
    with OpenVMS V6.1 which connects - via DECnet - to an RDB V6.0A DBI
    (V3.1A) d/b -ON THE SAME NODE. See note below for the reason for this
    indirection. This DBI d/b (called VDB) has a link via DBI-DB2 GWY
    (V3.1A) to DBI-DB2 Server V3.1. The DB2 version is V3.1 running under
    MVS/CICS in a region called P2. The SNA Gateway is an SNA Peer Server
    V1.3-1 with a 16 Mbit token-ring interface to the SNA network and a
    standard TurboChannel Ethernet card back to the rest of the LAN. The
    DECnet on VMS is DECnet/OSI V6.1 ECO4; on Digital UNIX (PeerServer)
    it's V3.2A-0.
    
    - Test
    
    For the test configuration the connection to the Alpha 2100 is the
    same (from the Sybase client) as for Production. The RDBAM server
    connects - via DECnet/OSI - to a DBI database on an Alpha 2000-300
    (ITSDEV) running DECnet Phase IV on VMS V6.1. The DBI database has a
    DBI-DB2 link to the same IBM system, but a different CICS region T2 -
    for test purposes. The software versions for RDB, DBI, and DBI-DB2 GWY
    are the same versions as those on COPY.
    
    NB:
    ---
    
    The major difference in the configurations from our side *seems* to be
    the DECnet stack - Phase IV in test and Phase V in Production. (We
    have Phase V purely to satisfy the requirements of the DECosap product
    - if Phase V proves to be a big issue, we may revert to Phase IV and
      suffer the consequences)
    
    Symptoms/Signs
    --------------
    
    In the Production environment a specific series of transactions
    through the RDBAM server produces - due to the DECnet indirection - 3
    hex longwords at the Sybase client. The numbers and translations
    follow:
    
    [-
    %RDB-F-SYS_REQUEST, error from system service request
    
    06C2A4BA -> %DBI-E-UDBTXN_START, Error starting transaction in an
    underlying database
    
    06C280D3 -> %DBI-I-LINK_INFO, Link name is '!AS' (The !AS is COM)
    
    C2A5DA4D -> So far have been unable to decipher this code. It isn't
    anything useful reading in either direction or doing any 'normal'
    byte/bit swapping associated with Big- vs little-endian in EBCDIC or
    ASCII.
    -]
    
    The volume of data on the T2 region is slightly less, but I have
    discounted this based on the fact that another sequence which runs
    prior to the failing group always works. The data volume for this
    sequence is at least an order of magnitude greater, however there are
    less tables used (4) in the working sequence than the failing sequence
    (13 till point of failure).
    
    Actions so far
    --------------
    
    1. Changed the RDBSERVER.COM procedure to turn on DB2_REQ_SQL and
    ERRORS DBI_TRACE_FLAGS.
    
    Found that the following sequence was appearing in the trace log for
    the offending server (multiple trace files are produced for the
    sequence of transfers we're using):
    
    ---EVENT BEG: DB2_REQ_SQL ---------------------- Mon Jul  8
    15:11:22.199 1996---
    
    SET TRANSACTION READ_ONLY
    ---EVENT END: DB2_REQ_SQL ---------------------- Mon Jul  8
    15:11:22.199 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.315 1996---
    %LDRV-E-LU62_SUPP, -SYSTEM-F-PATHLOST, path to network partner node
    lost
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.339 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.396 1996---
    %LDRV-E-LU62_SUPP, -SNALU62-E-GATCOM, error communicating with Gateway
    node
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.396 1996---
    
    --EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.023 1996---
    %LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.023 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.076 1996---
    %LDRV-E-GNL_COMMSVC_ERR, communication service error
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.077 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.133 1996---
    %RDB-F-IO_ERROR, input or output error
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.134 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.188 1996---
    %DBI-E-LOST_CON, Connection to database was lost
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.189 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.243 1996---
    %DBI-I-LINK_INFO, Link name is 'COM'
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.243 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.299 1996---
    %DBI-E-UDBTXN_START, Error starting transaction in an underlying
    %DBI-E-UDBTXN_START, Error starting transaction in an underlying
    database
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.299 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.355 1996---
    %DBI-E-UDBTXN_START, Error starting transaction in an underlying
    database
    -DBI-I-LINK_INFO, Link name is 'COM'
    -DBI-E-LOST_CON, Connection to database was lost
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.410 1996---
    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.422 1996---
    %RDB-F-SYS_REQUEST, error from system services request
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.422 1996---
    
    2. Logged a call with Digital for the network error and advice -
    recommendation is to upgrade DECnet/OSI to V6.3 ECO 4.
    
    
    Notes:
    ------
    
    1. The reason for the Omni-RDBAM d/b attach/connection via DECnet is
    that the RDBAM server crashes with an internal error after about 5
    select statements and a commit when attached directly using the DBI
    attach qualifiers without a node name. The RDBAM s/w works correctly
    with any RDB database I've cared to throw at it. Something about the
    DBI presentation seems to get RDBAM all bitter and twisted. The
    internal error is:
    
    [-
    Jul  3 08:57:12 1996: rdbam (spid 0): ERROR: 16150/10/0:
    Thread '5' is in danger of exceeding allotted stack space of 34800
    bytes
    .
    Jul  3 08:57:12 1996: rdbam (spid 0): FATAL SERVER ERROR:
    16151/20/0: Thread '5' has overflowed or corrupted its stack --
    aborting
    .
    Jul  3 08:57:12 1996: A fatal error detected by scheduler. Cannot
    continue
    -]
    

    can you connect to the test cics region and execute queries from rdb
    sql. just a direct attach to our db2 gateway?
    
    
    could also be a timeout, 
    
    thanks
    Steve
    
    
    btw...oh what a tangle web we weave!
    
    
    

This error message is a pretty good indication that the problem is decnet
based.  This means the node with the DBI/DB2 Gateway lost it's connection to
the Peer Server.  That means the problem is not on NT and it's not in the SNA
network.

I'm not a DECnet expert, but aren't there event logs which record errors?
I'd break out the DECnet Problem Determination Handbook (if there is
such a thing).

    
    ---EVENT BEG: ERRORS --------------------------- Mon Jul  8
    15:11:22.315 1996---
    %LDRV-E-LU62_SUPP, -SYSTEM-F-PATHLOST, path to network partner node
    lost
    ---EVENT END: ERRORS --------------------------- Mon Jul  8
    15:11:22.339 1996---