home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 19952 < prev    next >
Encoding:
Internet Message Format  |  1992-12-28  |  4.0 KB
  1. Path: sparky!uunet!news.claremont.edu!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
  2. From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: TT_AccPorNam field remains null on a SHOW USERS output ?
  5. Date: 28 Dec 1992 16:39:35 GMT
  6. Organization: HST Wide Field/Planetary Camera
  7. Lines: 67
  8. Distribution: world
  9. Message-ID: <1hnak7INNnna@gap.caltech.edu>
  10. References: <1992Dec27.233720.1@woods.ulowell.edu>
  11. Reply-To: carl@SOL1.GPS.CALTECH.EDU
  12. NNTP-Posting-Host: sol1.gps.caltech.edu
  13.  
  14. In article <1992Dec27.233720.1@woods.ulowell.edu>, sabotkap@woods.ulowell.edu writes:
  15. =From a terminal hardwired to the system (ours is VMS 5.4), the server/port
  16. =field is left blank (see below).  An attempt at using
  17. =f$getdvi("TT","TT_AccPorNam") also returns an empty string.
  18. =
  19. = Username  Node   Process Name    PID     Terminal
  20. = SABOTKA  CIRRUS  SABOTKA       202060C2  TTA0:
  21. =                                           ^ (hardwired terminal)
  22.  
  23. That's because the system has already identified, as fully as possible, the
  24. location from which the login is taking place.  Think:  There's no way for VMS
  25. to be able to tell you where the terminal cable goes once it leaves the VAX. 
  26. What information would you expect in the TT_ACCPORNAM field in this case?
  27.  
  28. =When logged in from a server, or remote system, the server/remote port
  29. =information is sometimes left blank:
  30.  
  31. = Username  Node   Process Name    PID     Terminal
  32. = SABOTKA  CIRRUS  P. Sabotka    20206DCB  LTA2633: (FOG::NETWORK)
  33. =                                                   ^ (we can't always get this)
  34.  
  35. Can you perhaps make at least a small attempt to figure out when you DO get
  36. this information and when you don't?
  37.  
  38. =When logged in from a non-hardwired terminal, when during login is the 
  39. =TT_AccPorNam information obtained ?  It seems a SET TERMINAL/INQUIRE in 
  40. =our SYLOGIN.COM is responsible for getting this field, but at other times, 
  41. =an otherwise normal login will not retreive this information.
  42.  
  43. The SET TERM/INQUIRE has absolutely *NO* effect on this.
  44.  
  45. =My motives: We have a captive account which we would like to monitor by 
  46. =            writing the login time, and any server/remote port information 
  47. =            to a log file.  
  48.  
  49. =I apologise for going a bit overboard with info about this problem, but I 
  50. =would rather explain it fully to any potential comp.os.vms.know-it-alls
  51. =who would flame me for lack of information  8-).
  52.  
  53. Well, let's see:
  54.     1)  You can't expect any information in TT_ACCPORNAM for hard-wired
  55.         terminals;
  56.     2)  DECnet sessions should have the remote node and username in the
  57.         TT_ACCPORNAM field, in the form node::user.
  58.     3)  LAT sessions should have the server name and port name in the
  59.         TT_ACCPORNAM field, in the form server/port;
  60.     4)  Since these are the ONLY three types of terminal sessions on
  61.         vanilla VMS, any other types of sessions are dependent on the
  62.         software you're running.
  63. So, as one of those comp.os.vms.know-it-alls, let me point out that you should
  64. at least make a token effort to answer the following questions:
  65.     1)  Are some of the sessions in question TELNET sessions?  If so, what
  66.         TCP/IP implementation are you using?
  67.     2)  Under what circumstances is the SERVER/PORT information left blank
  68.         (at a guess, it's when the person has TELNETed from the server.  Of
  69.         course, that would give a physical terminal name of something other
  70.         than LTAnnn:, but since you couldn't take the time to find one of
  71.         those mystery sessions, I doubt you'd be too careful about getting
  72.         the information in your made-up example scrupulously correct.
  73. --------------------------------------------------------------------------------
  74. Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL
  75.  
  76. Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
  77. understanding of astronomy is purely at the amateur level (or below).  So
  78. unless what I'm saying is directly related to VAX/VMS, don't hold me or my
  79. organization responsible for it.  If it IS related to VAX/VMS, you can try to
  80. hold me responsible for it, but my organization had nothing to do with it.
  81.