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

Conference vaxaxp::vmsnotes

Title:VAX and Alpha VMS
Notice:This is a new VMSnotes, please read note 2.1
Moderator:VAXAXP::BERNARDO
Created:Wed Jan 22 1997
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:703
Total number of notes:3722

697.0. "Slow LAT connection v. Fast Telnet connection??" by CHOWDA::GLICKMAN (writing from Newport,RI) Thu Jun 05 1997 15:39

    Help!
    
    We just experienced something really strange:
    
    If we did LAT connections to any one of 3 nodes in an OpenVMS 6.1
    VAXcluster we would get the SYS$ANNOUNCE message, Username: prompt
    and then it would take almost a minute before we got the Password:
    prompt.
    
    If we did Telnet connections to any one of 3 nodes in this same
    cluster at during this same time window we would get SYS$ANNOUNCE,
    Username: prompt and Password: prompt in seconds (probably less).
    
    Eventually we could make the connections either way just fine.
    
    Anyone have any ideas as to what was happening and why the difference
    between LAT and Telnet?
    
    If more information is required let me know.
    
    Thanks.
T.RTitleUserPersonal
Name
DateLines
697.1Difficult to diagnose after the fact...XDELTA::HOFFMANSteve, OpenVMS EngineeringThu Jun 05 1997 15:5218
   Given the consistency of the location of the problem in the login
   sequence, this would appear to be a host-related problem, not a
   transport problem.

   I'd expect there were some locks held on the system authorization
   files by some slower (batch) jobs, and that the difference between
   LAT vs Telnet is little more than a fluke.  (If these commands were
   interspersed, and a consistent transport-specific difference was
   noted, then there might be something going on in LAT...)

   Use DECamds -- see the OpenVMS documentation set for details on
   this seperately-installed tool -- to look at the locking.  Older
   versions of DECamds are licensed with a VMScluster -- more recent
   versions don't require a VMScluster license. 

   I'd suspect any information on the actual cause is long gone...