Conference orarep::nomahs::dbintegrator_public_public

    
    Hi M�rcia,
    
    We've never seen this, although it is possible we have it fixed in V7.
    In any case, memory usage characteristics have changed significantly in
    the updated version of DBI.
    
    Would it be possible for your customer to upgrade to V7?
    
    Also, could you send a pointer to the entire bugcheck?  We'd like to
    analyze it to see if we can tell exactly what was going on at the time.
    
    Thanks,
    
    Dan

    Hi Dan,
    
        The customer can't upgrade to V7.0 but I 'll copy the bugcheck dump
    so that you can take a look. I'll updtate this note as soon as I have
    the bugcheck here.
    
         Thanks .. Marcia

    Hi Dan,
    
        The bugcheck file is available in VAXRIO::dbi_bugcheck.marcia
    
    
      Thanks ... Marcia

    
    Hi Marcia,
    
    Could you copy the bugcheck file to orarep::?  That is the only node we
    have access to in terms of copying across the firewall.
    
    Thanks,
    
    Dan

Hi Dan,

     I forgot this, sorry.. I've already copied the file to orarep.

     orarep::dbi_bugcheck.marcia

     Thks,

         M�rcia

    
    Hi Marcia,
    
    I looked at the bugcheck, unfortunately there was some corruption in
    there (looks like a memory stomper) that caused the bugcheck to be less
    useful than we would have liked.  Is there any set of conditions that
    makes the problem reproducable?
    
    Thanks,
    
    Dan 

    
    Hi Marcia,
    
    On second look through the bugcheck we noticed something interesting -
    some of the contents of the stack have system-f-pathlost, path to
    network partner node lost.  Could there be a flaky network that is
    causing the transfer to fail, and which is also causing something to
    corrupt the stack?  Is there any sna logging or some such that would
    show a history of the sna connection?
    
    Thanks,
    
    Dan

    
    Hi Marcia (again),
    
    One of the DB2 gateway developers mentioned that a couple of bugchecks
    in the DB2 gateway that happen when sessions are lost were fixed in the
    V7.0 release.  This might be the answer if indeed the connection is
    being lost.
    
    Thanks,
    
    Dan

Hi Dan,

   
     Maybe the connection was lost. The funny thing is that many times when the 
connection is lost , the transfer logfile has some error messages talking about 
the problem but no bugcheck occurs.

     We don't have any log of sna. The customer is trying to reproduce the error.
The bugcheck happens intermittently.
If the error happens , we will try to get more information. The have the dbi trace 
logicals enabled to get more info. 

   Thanks .. Marcia

Hi Dan,

    We are having many connections errors .. I enabled the trace and that's part of 
the log generated (no bugcheck was generated though).  

    Is DBI responsible for this errors or the problem is related to SNA products ? 
    The version of SNALU62 is S2.2-03 . Sna people here told me that this version is 
old and that we could install version 2.2eco20.

    What do you think ?

    Thks,

       M�rcia

--EVENT BEG: ERRORS --------------------------- Mon Jan  6 12:24:10.250 1997---
%LDRV-E-LU62_SUPP, -SYSTEM-F-PATHLOST, path to network partner node lost
---EVENT END: ERRORS --------------------------- Mon Jan  6 12:24:10.270 1997---

---EVENT BEG: ERRORS --------------------------- Mon Jan  6 12:24:10.300 1997---
%LDRV-E-LU62_SUPP, -SNALU62-E-GATCOM, error communicating with Gateway node
---EVENT END: ERRORS --------------------------- Mon Jan  6 12:24:10.300 1997---

---EVENT BEG: ERRORS --------------------------- Mon Jan  6 12:24:10.310 1997---
%LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
---EVENT END: ERRORS --------------------------- Mon Jan  6 12:24:10.310 1997---

---EVENT BEG: ERRORS --------------------------- Mon Jan  6 12:24:10.350 1997---
%LDRV-E-GNL_COMMSVC_ERR, communication service error
---EVENT END: ERRORS --------------------------- Mon Jan  6 12:24:10.350 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Mon Jan  6 12:24:10.360 1997---
Exception: utl_e_invalid_mem_zone
---EVENT END: EXCEPTIONS ----------------------- Mon Jan  6 12:24:10.370 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Mon Jan  6 12:24:10.380 1997---
Exception: utl_e_invalid_mem_zone
---EVENT END: EXCEPTIONS ----------------------- Mon Jan  6 12:24:10.400 1997---

---EVENT BEG: ERRORS --------------------------- Mon Jan  6 12:24:10.410 1997---
%RDB-F-IO_ERROR, input or output error
---EVENT END: ERRORS --------------------------- Mon Jan  6 12:24:10.410 1997---

---EVENT BEG: ERRORS --------------------------- Mon Jan  6 12:24:10.000 1997---
%RDB-F-IO_ERROR, input or output error
-L

    
    Hi M�rcia,
    
    You should start by upgrading SNA - we haven't fixed (or had to fix)
    anything in the communications area via SNA in a very long time.  I
    would guess the problem is in the SNA software itself.
    
    Again, installing the latest version of the DB2 Gateway might fix the
    bugcheck problem, but I don't think it will get rid of the connection
    errors.
    
    Regards,
    
    Dan

Marcia,

- V7.0 most likely has the fix to avoid the bugchecks you are seeing,
  but it will not affect the root problem, the lost connections
  to the gateway.
- I agree that upgrading LU62 is a good idea, but not likely to affect
  the symptoms of this problem.

I think the real problem is with your DECnet connection to the gateway.
Can you get the customer to investigate any problems with that leg of
the network?

By the way, what kind of DEC/SNA Gateway is this and what is it's maintenance
level.  $MCR SNAP from the DECnet load host should tell you this.

    Hi,
    
       I got the information you asked about the gateway.  It doesn't seem
    to be a decnet problem because I asked to a specalist of sna nd decnet
    to take a look at the customer system.
    
       We had another connection error and I saved a part of the dbi_trace.
    
       They have dbi 3.1 and we are thinking of installing snalu 2.3 .. is
    this ok ? 
    
       Here the informations and trace file.
    
       Thks ,
    
              M�rcia
    
---EVENT END: DB2_MSG -------------------------- Fri Jan 10 04:02:43.380 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:46.370 1997---
%LDRV-E-LU62_SUPP, -SNA-E-LOGUNIDEA, SSCP has deactivated the session
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:46.410 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:46.000 1997---
%LDRV-E-LU62_SUPP, -SNALU62-E-NOTACT, SNA session no longer active
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:46.000 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:46.030 1997---
%LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:46.030 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:46.050 1997---
%LDRV-E-GNL_COMMSVC_ERR, communication service error
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:46.050 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Fri Jan 10 04:02:46.080 1997---
***************
---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:46.220 1997---
%RDB-F-IO_ERROR, input or output error
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:46.250 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:46.270 1997---
%RDB-F-IO_ERROR, input or output error
-LDRV-E-GNL_COMMSVC_ERR, communication service error
-LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
-LDRV-E-LU62_SUPP, -SNALU62-E-NOTACT, SNA session no longer active
-LDRV-E-LU62_SUPP, -SNA-E-LOGUNIDEA, SSCP has deactivated the session
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:46.270 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Fri Jan 10 04:02:48.180 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Fri Jan 10 04:02:48.180 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:48.230 1997---
%LDRV-E-LU62_SUPP, %SNALU62-S-OK, normal successful completion
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:48.230 1997---

---EVENT BEG: ERRORS --------------------------- Fri Jan 10 04:02:48.270 1997---
%LDRV-E-GNL_COMMSVC_ERR, communication service error
---EVENT END: ERRORS --------------------------- Fri Jan 10 04:02:48.330 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Fri Jan 10 04:02:48.380 1997---
       
    -----------------------------------
09-Jan-1997 16:46:13   Node: G60000 (1.242)   DECnet SNA Gateway-CT V2.1-07
Uptime:   4 21:09:07   Host:  (1.513)         MicroLES nonrouting IV

 Ses  124/ 508 XXXXXXXXXXX!-------------------------------------   Pool
 Lnk  180/ 256 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX!--------------   3183792
 Buf       32% XXXXXXXXXXXXXXX!---------------------------------
 Sys       34% XXXXXXXXXXXXXXXX!--------------------------------   LPDs
 Usr        0% -------------------------------------------------   508
                        .         .         .         .         .
 LUs     SNA-0 .23....89...3.5....0..3.5.7.901....6..90...4..78.0  PUs
               1.3.56.890.234567.901.3..6789012...6.8901234567.90  2 (2)
               12345.7890..3.567890....567.90....................
               ....5.....12345678901234567.901.....7..0.........0
               ....5678.012345678901...5....01.3456789012345.....
               ....5.............................................

Server       Lnk Ses LUs
SNA$GAS      175 112 176
SNA$RJE        3  12  12
SNA$EVC        1
SNA$SNAP       1
 
 
Access Name Characteristics as of  9-JAN-1997 16:46:59 from G60000

Access name = VIDA
 
PU                       = SNA-1
LU list                  = 2,3,41-48
Logon mode               = XL622048
Application              = RJAACICS

 
 
 
PU Counters as of  9-JAN-1997 16:47:08 from G60000

PU = SNA-1
 
      421637  Seconds since last zeroed
           0  Valid REQMS received
           0  Invalid REQMS received
           0  REQMS receive threshold exceeded
           1  ACTPUs received, including:
                ACTPUs (ERP)
           0  Negative responses
           0  DACTPUs received
         434  Total ACTLUs received
         180  Total DACTLUs received
         254  Active LUs

 
 
 
Circuit Counters as of  9-JAN-1997 16:47:18 from G60000

Circuit = CHAN-1
 
      421647  Seconds since last zeroed
   565196779  Bytes received
    11819208  Bytes sent
      442085  Data blocks received
      351686  Data blocks sent
           0  Remote process errors
      529270  Attentions sent
      285443  Attentions sent on read
      259533  Write channel programs
      561614  Read channel programs

 
 
 
Known Line Counters as of  9-JAN-1997 16:47:24 from G60000

Line = CQ-0
 
      421653  Seconds since last zeroed
     6858690  Commands received
     7767246  Channel operations executed
   791097925  Bytes received
   195898036  Bytes sent
     1585266  Blocks received
     1980512  Blocks sent
         351  Channel events, including:
                System reset
                Selective reset
           0  Process errors
           0  Channel errors
         160  Local buffer errors, including:
                Receive buffer ring empty
          64  Buffers in use at peak
           3  Attention buffers at peak

 
    

    SSCP has disconnected the session.  SSCP is on the IBM mainframe.  The
    mainframe is the Primary Logical Unit.  If the IBM mainframe wants to 
    terminate the session there's nothing we (SNA gateway) can do about it.
    
    How about running session level SNA traces and capturing the
    disconnect and then confront the IBM folks with the exact date/time the
    session was dropped?  They'll have their own logs to check based on
    your timestamp.
    
    In a previous reply Dave was right about the network connections
    getting dropped.  This latest trace says that the IBM side is
    requesting the disconnect.  
    
    Don
    
    

    Hi Marcia,
    
    Here's something else that may help you.  I don't know about the newest
    SNA gateways but this works for the ST & CT gateways that were real
    popular.  And if the newer gateways don't use the exact same utility
    then they have a similar utility.
    
    You can trap counters on the SNA gateway at the LU level. The LU's on
    a SNA gateway are like circuits in DECnet.  Say that your DB2 gateway
    configuration has 3 dedicated LU's (1, 2, 3) going to some IBM
    application.  You can use the SNANCP utility from the DECSNA management
    software and check the counters for each LU.  You have to know which
    port on the SNA gateway you physically use too.  The SNA gateway system
    manager can tell you this.
    
    $ mcr snancp
    SNANCP> USE SYSTEM my_sna_gtwy_name
    SNANCP> SHOW LU sna-0.2 COUNTERS
    
    This would show counter info for LU number 2 on port sna-0. You could
    zero the counters out and then check them later by doing 
    
    SNANCP> ZERO LU sna-0.2
    
    One of the counters is DACTLU and this keeps track of the deactivate LU
    messages it receives.  If the SNA gateway manager doesn't mind ask if
    you can zero out all the LU counters.  This way you could compare
    DACTLU's of your IBM application against other non-DB2 applications.
    Also, say that your LU's are numbers 1-3 you could also check to see
    if all LU's 1-3 have received the same number of DACTLU's.
    
    The trace said that the SSCP deactivated the session. If the primary 
    logical unit (PLU) tells the secondary logical unit (SLU and in this
    case the SNA gateway) to disconnect then that's what happens. It's
    always good to have exact timestamps and dates because the IBM SNA
    system managers can usually help track events with their own logs
    with this information. 
    
    Upgrading LU6.2 is probably a good idea because that's a real old
    version you have but this looks like it could be expected behavior
    from the SNA gateway/DB2 gateway perspective.
    If this is happening a lot then why (counters will help)?  The IBM
    SNA system managers can trace your LU's from their side too.
    
    I'm not just pointing a finger at the IBM side Marcia.  Most SNA
    gateway related problems get solved by the DEC and the IBM people
    working together.  I used to support SNA gateways a very long long
    long long time ago.    8^)
    
    Don

Hi Don,
    
    
      We have upgraded SNALU to V2.3. Another bugcheck happened and the
    dbi trace had the following messages. It looks like an IBM problem but
    I'm not sure. Do you have an idea what these messages mean ?
    
      Thanks .. Marcia
    
 0000 : 07d87d63 00001b                     : .Q'...\
  ----   -------- -------- -------- --------   ----------------

---EVENT END: DB2_MSG -------------------------- Thu Jan 16 21:39:28.021 1997---

---EVENT BEG: ERRORS --------------------------- Thu Jan 16 21:39:49.050 1997---
%LDRV-E-LU62_SUPP, -SNALU62-E-HOSTERR, error returned from host,<CR>
        DFHAC2206 21:38:44 RJAACICS TRANSACTION DC20 HAS FAILED WITH ABE

ND AEY9. RESOURCE BACKOUT WAS SUCCESSFUL.  
---EVENT END: ERRORS --------------------------- Thu Jan 16 21:39:49.110 1997---

---EVENT BEG: ERRORS --------------------------- Thu Jan 16 21:39:49.130 1997---
%LDRV-E-LU62_SUPP, %SNALU62-E-DEABPR, deallocate abend program
---EVENT END: ERRORS --------------------------- Thu Jan 16 21:39:49.140 1997---

---EVENT BEG: ERRORS --------------------------- Thu Jan 16 21:39:49.160 1997---
%LDRV-E-GNL_SRVR_ERROR, server software terminated abnormally
---EVENT END: ERRORS --------------------------- Thu Jan 16 21:39:49.160 1997---

    

AEY9 means CICS is no longer talking to the DB2 subsystem.  Usually
means the customer forgot to do CICS command DSNC STRT after DB2
was restarted.

I've never seen this cause a bugcheck in the DBI/DB2 image.  Are you sure
this is creating a bugcheck dump file on the VMS system?

Or, are you simply calling error messages bugchecks?
Or, perhaps you're referring to the word ABEND in the message
from CICS?

If there really is a bugcheck dump file on the VMS system due to this
message then please get it submitted since it would represent a new problem.

    Hi,
    
      We had a transfer executing that  failed and in the log it
    says that a bugcheck was generated. I didn't find these messages on the
    bugcheck. But , we had dbi trace enabled and the trace showed these errors.
    So I assumed that the transfer failed , generated the bugcheck but
    that the cause was the problem with cics.
    
     I 'll copy the bugcheck and sent you.
     
     I'll update this note as soon as I have the bugcheck.
    
      M�rcia

    Hi,
    
       I copied the bugcheck to orarep::dbi_bugcheck.marcia. 
    
      Thks .. Marcia

    Hi Marcia,
    
    Dave looked at your bugcheck file and feels that upgrading to V7 is the 
    way to go as this will most likely fix the bugcheck problem.  This will
    not fix the real problem which is lost SNA connections.  We handle lost
    SNA sessions more gracefully in V7.
    
    I'd still keep running SNA session level traces, and check SNA LU
    counters so that you'll have material which shows the connection being
    dropped at such a date and such a time.  Then bring this information to
    the IBM and DEC SNA system people and see what they think.  
    
    Could this be a timing problem?  Could a DDD transfer be scheduled at a 
    time that overlaps with some IBM system maintenance?  
    
    Lastly, do they use DBI at all?  Upgrading the DB2 gateway to V7 will
    put a new V7 DBI image on the system.  Or are they only using this 
    particular gateway and Rdb Replication Option?  
    
    Don  

    Hi Don,
    
        Yesterday another transfer failed and Dbi trace shows another
    connection error .. I would like to confirm with you if this connection
    problem is caused by the IBM side...
    
        Thanks .. M�rcia 
    
    PS: We are already running SNALU 2.3

---EVENT BEG: ERRORS --------------------------- Tue Jan 21 15:53:03.320 1997---
%LDRV-E-LU62_SUPP, -SNALU62-E-EXIT, Gateway server task terminated
---EVENT END: ERRORS --------------------------- Tue Jan 21 15:53:03.420 1997---

---EVENT BEG: ERRORS --------------------------- Tue Jan 21 15:53:03.011 1997---
%LDRV-E-LU62_SUPP, -SNALU62-E-GATCOM, error communicating with Gateway node
---EVENT END: ERRORS --------------------------- Tue Jan 21 15:53:03.011 1997---

---EVENT BEG: ERRORS --------------------------- Tue Jan 21 15:53:03.021 1997---
%LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
---EVENT END: ERRORS --------------------------- Tue Jan 21 15:53:03.041 1997---

---EVENT BEG: ERRORS --------------------------- Tue Jan 21 15:53:03.061 1997---
%LDRV-E-GNL_COMMSVC_ERR, communication service error
---EVENT END: ERRORS --------------------------- Tue Jan 21 15:53:03.061 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:04.010 1997---
Exception: GNL_ERROR_EXIT
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:04.020 1997---

---EVENT BEG: ERRORS --------------------------- Tue Jan 21 15:53:04.080 1997---
%RDB-F-IO_ERROR, input or output error
---EVENT END: ERRORS --------------------------- Tue Jan 21 15:53:04.080 1997---

---EVENT BEG: ERRORS --------------------------- Tue Jan 21 15:53:04.080 1997---
%RDB-F-IO_ERROR, input or output error
-LDRV-E-GNL_COMMSVC_ERR, communication service error
-LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
-LDRV-E-LU62_SUPP, -SNALU62-E-GATCOM, error communicating with Gateway node
-LDRV-E-LU62_SUPP, -SNALU62-E-EXIT, Gateway server task terminated
---EVENT END: ERRORS --------------------------- Tue Jan 21 15:53:04.100 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:04.140 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:04.140 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.190 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.200 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.370 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.370 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.410 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.410 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.020 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.040 1997---

---EVENT BEG: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.140 1997---
Exception: DBI_RETURN_MORE
---EVENT END: EXCEPTIONS ----------------------- Tue Jan 21 15:53:05.140 1997---


       

I cut the error messages out of your previous postings in order to
clarify the root problem.  That way you won't have to post every
error message here asking what to do.


1) These two error message sequences are the real problem:


   %LDRV-E-LU62_SUPP, -SYSTEM-F-PATHLOST, path to network partner node lost
   %LDRV-E-LU62_SUPP, -SNALU62-E-GATCOM, error communicating with Gateway node
   %LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
   %LDRV-E-GNL_COMMSVC_ERR, communication service error


   %LDRV-E-LU62_SUPP, -SNALU62-E-EXIT, Gateway server task terminated
   %LDRV-E-LU62_SUPP, -SNALU62-E-GATCOM, error communicating with Gateway node
   %LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
   %LDRV-E-GNL_COMMSVC_ERR, communication service error


   You are having DECnet problems which is breaking the link between the
   node with DBI and the SNA Gateway.  The DB2 Gateway has a timing problem
   in that it may bugcheck *after* the link is dropped.  So, if you fix the
   network the bugcheck goes away.  You can install DBI7 and the bugchecks
   will *probably* go away, but you'll still get these error sequences.

   Your DECnet people should have the skills to detect why links are dropping.
   Get them to look at the network and fix the base problem!


2) This error message is indeed an IBM problem.  If you see the SSCP
   deactivating a session then call your IBM side.  These do not
   normally dump, however, it could cause the timing sequence which DBI7 fixes.

   %LDRV-E-LU62_SUPP, -SNA-E-LOGUNIDEA, SSCP has deactivated the session
   %LDRV-E-LU62_SUPP, -SNALU62-E-NOTACT, SNA session no longer active
   %LDRV-E-LU62_SUPP, %SNALU62-E-RESFRET, resource failure retry
   %LDRV-E-GNL_COMMSVC_ERR, communication service error

3) Any messages with DFHxxxxxx or DSNTxxxxxx appearing in the
   %LDRV-E-LU62_SUPP text are generated either by CICS or by DB2.
   These do not cause dumps.

   %LDRV-E-LU62_SUPP, -SNALU62-E-HOSTERR, error returned from host,<CR>
        DFHAC2206 21:38:44 RJAACICS TRANSACTION DC20 HAS FAILED WITH ABE
        ND AEY9. RESOURCE BACKOUT WAS SUCCESSFUL.  
   %LDRV-E-LU62_SUPP, %SNALU62-E-DEABPR, deallocate abend program
   %LDRV-E-GNL_SRVR_ERROR, server software terminated abnormally