From: carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: Re: TT_AccPorNam field remains null on a SHOW USERS output ?
Date: 28 Dec 1992 16:39:35 GMT
Organization: HST Wide Field/Planetary Camera
Distribution: world
Reply-To: carl@SOL1.GPS.CALTECH.EDU
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <1992Dec27.233720.1@woods.ulowell.edu>, sabotkap@woods.ulowell.edu writes:
=From a terminal hardwired to the system (ours is VMS 5.4), the server/port
=field is left blank (see below).  An attempt at using
=f$getdvi("TT","TT_AccPorNam") also returns an empty string.
=
= Username  Node   Process Name    PID     Terminal
= SABOTKA  CIRRUS  SABOTKA       202060C2  TTA0:
=                                           ^ (hardwired terminal)

That's because the system has already identified, as fully as possible, the
location from which the login is taking place.  Think:  There's no way for VMS
to be able to tell you where the terminal cable goes once it leaves the VAX. 
What information would you expect in the TT_ACCPORNAM field in this case?

=When logged in from a server, or remote system, the server/remote port
=information is sometimes left blank:

= Username  Node   Process Name    PID     Terminal
= SABOTKA  CIRRUS  P. Sabotka    20206DCB  LTA2633: (FOG::NETWORK)
=                                                   ^ (we can't always get this)

Can you perhaps make at least a small attempt to figure out when you DO get
this information and when you don't?

=When logged in from a non-hardwired terminal, when during login is the 
=TT_AccPorNam information obtained ?  It seems a SET TERMINAL/INQUIRE in 
=our SYLOGIN.COM is responsible for getting this field, but at other times, 
=an otherwise normal login will not retreive this information.

The SET TERM/INQUIRE has absolutely *NO* effect on this.

=My motives: We have a captive account which we would like to monitor by 
=            writing the login time, and any server/remote port information 
=            to a log file.  

=I apologise for going a bit overboard with info about this problem, but I 
=would rather explain it fully to any potential comp.os.vms.know-it-alls
=who would flame me for lack of information  8-).

Well, let's see:
	1)  You can't expect any information in TT_ACCPORNAM for hard-wired
	    terminals;
	2)  DECnet sessions should have the remote node and username in the
	    TT_ACCPORNAM field, in the form node::user.
	3)  LAT sessions should have the server name and port name in the
	    TT_ACCPORNAM field, in the form server/port;
	4)  Since these are the ONLY three types of terminal sessions on
	    vanilla VMS, any other types of sessions are dependent on the
	    software you're running.
So, as one of those comp.os.vms.know-it-alls, let me point out that you should
at least make a token effort to answer the following questions:
	1)  Are some of the sessions in question TELNET sessions?  If so, what
	    TCP/IP implementation are you using?
	2)  Under what circumstances is the SERVER/PORT information left blank
	    (at a guess, it's when the person has TELNETed from the server.  Of
	    course, that would give a physical terminal name of something other
	    than LTAnnn:, but since you couldn't take the time to find one of
	    those mystery sessions, I doubt you'd be too careful about getting
	    the information in your made-up example scrupulously correct.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: CARL@SOL1.GPS.CALTECH.EDU | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.
Newsgroups: comp.os.vms