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

Conference vmszoo::vmsmail

Title:VMS Mail Utility Suggestions and Discussions
Moderator:EPS::VANDENHEUVEL
Created:Thu Feb 13 1986
Last Modified:Tue Jun 03 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:1943
Total number of notes:8236

1930.0. "Mail prompt takes 2.5 mins to return, is it DNS related ?" by COMICS::SUMNERC (OpenVMS Counter Intelligence) Fri Feb 07 1997 09:55

    Hi,
    
    
    I have a customer saying that sometimes the MAIL> prompt is taking
    2.5 minutes to come back from a $MAIL command.
    
    When he reboots the DECdns server the MAIL problem goes away and
    everything works as normal.  All other DCL commands are fine (working
    as normal).
    
    This happens with connections over LAT and telnet.  The problem seems
    fairly consistent at about 2.5 minutes.  My customer has been doing
    Control-t at the $ prompt, typing MAIL and doing another control-t
    which only gets actioned when the MAIL> prompt appears. Here are a
    couple of examples -
    ------------------------------------------------------------------------
    $
    NOTLIB::_TNA6437: 16:13:37   (DCL)   CPU=00:00:00.20 PF=385 IO=150
    MEM=74
    $ mail
    NOTLIB::_TNA6437: 16:16:09 MAIL      CPU=00:00:00.27 PF=473 IO=164
    MEM=140
    
    MAIL>
    
    ------------------------------------------------------------------------
    
    NOTLIB::SYSTEM 16:12:46   (DCL)   CPU=00:00:00.31 PF=774 IO=470 MEM=66
    $ mail
    NOTLIB::SYSTEM 16:15:19 MAIL      CPU=00:00:00.33 PF=867 IO=484 MEM=132
    
    ------------------------------------------------------------------------
    
    My question to any MAIL guru's is... what is happening when MAIL is
    activated ?  Is this establishing comms to the DNS server if one is
    available.  I could understand this on doing a send.
    
    Thanks in advance for any help,
    
    Chris Sumner
    Server Management Support, UK. 7833 3667
    
    PS. My customer supplied the following details & info:
    Hardware: 
    Alpha system running OpenVMS 6.2-1H3, DECnet/OSI 6.3 ECO 5
    There is one UTP connection to the outside world which goes into a 
    mini-hub and hence to an ethernet switch. The hub is shared with a
    DECserver700 and a DEMSA for X.25 connectivity.
    
    Software: The Alpha is running DECnet, UCX and LAT. The DECnet
    application MAIL is configured as I would expect. I can see 
    NET$SERVER.LOG files for the various attempts made and I tried to see 
    what was going on by defining NetServer$VERIFY as a logical but I get 
    nothing.
    
    "The only other oddity that I can spot is that mail sent via DECnet from 
     another system fails with "Remote system is unreachable" but SMTP mail 
     (the Alpha is running UCX 4.1 (no ECO) is delivered normally."
T.RTitleUserPersonal
Name		DateLines
1930.1try MC CDI$TRACEVELI::KORKKOVeli K�rkk� @FNO, 879-5512Sun Feb 09 1997 15:0912
        How about doing
        
        
        $ spawn/nowait mc cdi$trace
        $ mail
        
        Maybe this will reveal some obscure DECdns activity. In fact,
        testing this on my OpenVMS V7.1/DECnet OSI V7.1 system shows
        that DECdns activity takes place, activity being related to
        sys$node or sys$node_fullname, maybe some sort of verification?
        
        _veli
1930.2COMICS::SUMNERCOpenVMS Counter IntelligenceMon Feb 10 1997 03:298
    Hi,
    
    Thanks.  I'll try and look at this today, in the mean time, would it be
    possible to mail me the trace, or the relevant sections ?
    
    Thanks again,
    
    Chris
1930.3Low Level Network Problem?XDELTA::HOFFMANSteve, OpenVMS EngineeringMon Feb 10 1997 16:25108
   That this happens with LAT and telnet connections is *really* weird,
   and might point to a more common cabling or low-level network fault
   -- these protocols are unrelated to DECdns, save for at the very
   lowest levels of the network communications paths.  (Cable, wire,
   transceiver, etc.)

   I'd also look around in the DECnet-Plus (HELP::DECNET-OSI_FOR_VMS)
   notes conference, as it's doubtful this has anything directly to do
   with MAIL -- I'd look around at the DECdns server software version
   running in the network, and at any known problems with it.  (The ZKO
   site has seen some similar DECdns glitches.)

   See HELP::DECNET-OSI_FOR_VMS -- there have been a large number of
   DECdns discussions over there.

   Here's the CDI$TRACE output from a local OpenVMS Alpha V6.2 system
   running DECnet-Plus...

$ mail
16:24:40
16:24:40                     [DECnet/CDI Request 113913]
16:24:40 Checking syntax of "DEC:.ZKO.AJAX"
16:24:40 [170027] Syntax check requested
16:24:40 [170027]   DECdns:  DEC:.ZKO.AJAX
16:24:40 [170027] valid syntax
16:24:40
16:24:40                     [DECnet/CDI Request 113914]
16:24:40    == 113914 ==   DECnet/CDI lookup request for "DEC:.ZKO.AJAX"   ====
16:24:40
16:24:40     - 113914 -  first, look up node "DEC:.ZKO.AJAX"  ---
16:24:40
16:24:40 [170028] lookup 170028: "DEC:.ZKO.AJAX"
16:24:40 (CDI cache) looking for "DEC:.ZKO.AJAX"
16:24:40 (CDI cache) DEC:.ZKO.AJAX found (cache slot 124):
16:24:40 (CDI cache)      tower len = 115
16:24:40 (CDI cache)      fullname = "DEC:.ZKO.AJAX"
16:24:40 (CDI cache)      synonym = "ajax"
16:24:40 (CDI cache)      towerset(last 8 bytes):                 13-AA-00-04-00
-35-4C-20
16:24:40 [170028] -- Entry found in cache --
16:24:40 [170028] Fullname: DEC:.ZKO.AJAX
16:24:40 [170028] Synonym: ajax
16:24:40 [170028] Towerset length: 115
16:24:40
16:24:40     - 113914 -  last, look up compressed name "AJAX" towerset  ---
16:24:40
16:24:40 [170029] lookup 170029: "AJAX"
16:24:40 (CDI cache) looking for "AJAX"
16:24:40 (CDI cache) AJAX found (cache slot 122):
16:24:40 (CDI cache)      tower len = 59
16:24:40 (CDI cache)      fullname = "LOCAL:.AJAX"
16:24:40 (CDI cache)      synonym = "AJAX"
16:24:40 (CDI cache)      towerset(last 8 bytes):                 13-AA-00-04-00
-35-4C-20
16:24:40 [170029] -- Entry found in cache --
16:24:40 [170029] Fullname: LOCAL:.AJAX
16:24:40 [170029] Synonym: AJAX
16:24:40 [170029] Towerset length: 59
16:24:40
16:24:40 CDI request 113914 complete, returning to Session
16:24:40     with lookup status "CDI operation successful"
16:24:40
16:24:40
16:24:40                     [DECnet/CDI Request 113915]
16:24:40 Checking syntax of "DEC:.ZKO.STAR"
16:24:40 [170030] Syntax check requested
16:24:40 [170030]   DECdns:  DEC:.ZKO.STAR
16:24:40 [170030] valid syntax
16:24:40
16:24:40                     [DECnet/CDI Request 113916]
16:24:40    == 113916 ==   DECnet/CDI lookup request for "DEC:.ZKO.STAR"   ====
16:24:40
16:24:40     - 113916 -  first, look up node "DEC:.ZKO.STAR"  ---
16:24:40
16:24:40 [170031] lookup 170031: "DEC:.ZKO.STAR"
16:24:40 (CDI cache) looking for "DEC:.ZKO.STAR"
16:24:40 (CDI cache) DEC:.ZKO.STAR found (cache slot 123):
16:24:40 (CDI cache)      tower len = 59
16:24:40 (CDI cache)      fullname = "DEC:.ZKO.STAR"
16:24:40 (CDI cache)      synonym = "star"
16:24:40 (CDI cache)      towerset(last 8 bytes):                 13-AA-00-04-00
-80-4C-20
16:24:40 [170031] -- Entry found in cache --
16:24:40 [170031] Fullname: DEC:.ZKO.STAR
16:24:40 [170031] Synonym: star
16:24:40 [170031] Towerset length: 59
16:24:40
16:24:40     - 113916 -  last, look up compressed name "STAR" towerset  ---
16:24:40
16:24:40 [170032] lookup 170032: "STAR"
16:24:40 (CDI cache) looking for "STAR"
16:24:40 (CDI cache) STAR found (cache slot 121):
16:24:40 (CDI cache)      tower len = 59
16:24:40 (CDI cache)      fullname = "DEC:.ZKO.star"
16:24:40 (CDI cache)      synonym = "star"
16:24:40 (CDI cache)      towerset(last 8 bytes):                 13-AA-00-04-00
-80-4C-20
16:24:40 [170032] -- Entry found in cache --
16:24:40 [170032] Fullname: DEC:.ZKO.star
16:24:40 [170032] Synonym: star
16:24:40 [170032] Towerset length: 59
16:24:40
16:24:40 CDI request 113916 complete, returning to Session
16:24:40     with lookup status "CDI operation successful"
16:24:40

MAIL>  Exit