From: MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 4-JAN-1993 08:23:44.34 To: info-vax@kl.sri.com CC: Subj: Re: TT_AccPorNam field remains null on a SHOW USERS output ? In article <28DEC199204082079@spades.aces.com>, Ehud writes: >In article <1992Dec27.233720.1@woods.ulowell.edu>, sabotkap@woods.ulowell.edu writes... > > [ misc. discussion deleted ] > >#When logged in from a non-hardwired terminal, when during login is the >#TT_AccPorNam information obtained ? > >Before SYLOGIN gets control is enough that you need to know. > In other words, Ehud doesn't know. In any case, since I'm experienced in these matters, I'll take a crack at it. Please refer to module $TTYUCBDEF in SYS$LIBRARY:LIB.MLB. This is the macro which symbolically defines the terminal-independent UCB extentions (not to be confused with port-specific extentions, such as DECnet, LAT, etc., which are indigenous to the port driver itself). I don't know what your level of technical expertise is, so please do not be offended if I either over-simplify or appear condescending. And by all means, PLEASE ASK QUESTIONS! ESPECIALLY THE -DUMB- ONES, because they usually are the ones that need to be asked. If you are embarassed (or frankly don't want to get flamed for asking), feel free to e-mail them to me, and I'll either answer them privately or anonymously with a post. By convention, device drivers use register five (R5) as a pointer to the device's "unit control block" (UCB). The UCB is a data structure contained within S0 space, in a region known as "non-paged pool," and is used to identify any given device on the system. Using your example, let's say you are logged in on terminal LTA2633:. if you were to run the System Dump Analyzer via the "$ ANA/SYS" command, and then type in the command: SDA> show device lta17: it would give you a display that roughly resembles: +----------------------------------------------------------------------------- LTA17 VT300_Series UCB address: 80B052C0 Device status: 00000010 online Characteristics: 0C040007 rec,ccl,trm,avl,idv,odv 00000200 nnm Owner UIC [000001,000004] Operation count 20444 ORB address 80B05530 PID 001F0006 Error count 0 DDB address 80D9E600 Class/Type 42/70 Reference count 5 DDT address 80B45041 Def. buf. size 80 BOFF 0001 CRB address 80D65680 DEVDEPEND 180093A0 Byte count 0200 I/O wait queue empty DEVDEPND2 F9E03004 SVAPTE 80B07190 FLCK index 34 DEVSTS 0001 DLCK address 80A176F0 *** I/O request queue is empty *** SDA> +----------------------------------------------------------------------------- Please note the far-right side of the first line, where it says "UCB address:". This is the system virtual address in Non-Paged Pool of where the UCB is located. Now, type in: SDA> read sys$system:sysdef.stb this causes SDA to read in the symbolic offset definitions for various data structures inside of VMS, including the UCB ones. Note the eight-digit hexidecimal number, and type in: SDA> format xxxxxxxx replacing the 'xxxxxxxx' with the eight-digit hex address of the UCB. Be ready to press the HOLD SCREEN key! There are two fields you will be interested in trying to find. They are: UCB$W_TT_PRTCTL -and- UCB$L_TT_ACCPORNAM The first entry is a 16-bit word, and it stands for "Port Control." It is used as a set of flags for denoting the operational status and configuration of the port driver side of the paradigm. One of the bit flags (#13, actually) inside of PRTCTL is "TTY$V_PC_ACCPORNAM". When this bit is set, it denotes there is an Access name associated with the port. The second entry, "UCB$L_TT_ACCPORNAM," is a 32-bit longword. When TTY$V_PC_AccPorNam is set, UCB$L_TT_AccPorNam contains the address (ie, "it points to") of a "counted ASCII string." A counted ASCII string simply means that the first byte of the string is interpreted as a binary value containing the number of ASCII characters to follow. The address contained within UCB$L_TT_AccPorNam does not necessarily have to be within the UCB. It can be anywhere within a legimate non-paged pool address. Now, having said all of that, I'll answer your question: >#When logged in from a non-hardwired terminal, when during login is the >#TT_AccPorNam information obtained ? That is left entirely up to the port driver, or port driver/ACP combination. Typically, it happens when the network connection is being established. This usually coincides with the creation of the UCB itself, during a process called "UCB cloning." I won't engorge into the details here, but if there is enough interest, I'll be happy to start another thread, illustrating the process with code fragments. Anyway, when the application issues the $ASSIGN system service against the root device (such as INET0:, NET0:, LTA0:, etc.), there is a flag indicating the root as a "template device." The appropriate Exec routine then allocates the requisite amount of non-paged pool, copies the template device into it, does all of the linkages and hocus-pocus, and you now have a new device on the system! The service then calls the device driver at its "CLONEDUCB" entry point. This is where the device driver gets to do any specific housekeeping associated with the new device. In the case of your question, that includes generating a suitable port name. Now, if you write your own device drivers, you can modify the port name at any time. One such driver I wrote dealt with reverse-TELNET printer connections to Xylogics terminal servers, as well as auto-launching applications without having to go through LOGINOUT. In that case, the formulation of the port name was NOT done inside of the driver, but was passed from the server process via the IO$_TTY_PORT function code as a character string. >#It seems a SET TERMINAL/INQUIRE in our SYLOGIN.COM is responsible for >#getting this field, > >Nope. If the information is available, it is there long before >SYLOGIN. > >#but at other times, an otherwise normal login will not retreive this >#information. > >Coincidence. > Incorrect. "Coincidence" implies that VMS collectively is somehow waffling on whether or not to insert the port name. That is highly doubtful. So, there must be an as-yet undetermined agent causing this behavior. Or, as Sir Arthur Conan Doyle would say, "The game is afoot." Let's start with the basics. On this dichotic behavior (sometimes it shows, sometimes it doesn't), can you narrow it down to a specific device type or group of devices? IE, can you narrow it down to "just LAT" devices or "just DECnet," etc? Or does it happen on all terminal devices, regardless of type (IE, does it equally affect TCP/IP, DECnet, and LAT)? Does it affect only one system, all systems, or only a subset of systems? If only a subset, is there anything (such as software) which is common to all of them, and them alone? Here's a biggie: Are you running any sort of custom or third-party software that requires CMKRNL privilege, and/or utilizes its own drivers and/or ACPs? And, have you INSURED that the software is CERTIFIED for VMS v5.4? In particular, any sort of terminal or security monitoring application that allows you to transcribe a terminal's dialogue, or to force keystrokes into the input buffer? >#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. ># That's perfectly legimate. Go for it! In reviewing your examples above, I saw you refer to "TTA0:". Do you have hard-wired terminal devices on your system, in addition to network-abstracted terminals? Is the problem limited only to your hard-wired terminals? If so, then I think we've narrowed down the problem. >#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-). > > [ Unwarranted reprimand deleted ] > Don't apologize. If anything, -you- are owed an apology for being unjustly "slimed" by other inhabitants of this newsgroup. > >SET TERM/INQ in SYLOGIN is a reason for you to be shot, by the way... > Huhh?? Earth to Ehud, Earth to Ehud, start breathing, Ehud. You're running out of oxygen... Now, way back in VMS v3.x or v4.x, you -could- invoke a system crash by having an unfortunately-placed SET TERM command in either your SYLOGIN or LOGIN procs, assuming you have LOG_IO privilege, and then submit a batch job where you end up attempting to do a SET TERM to a disk drive. The last time I saw that problem was, ohh, nine or ten years ago. More commonly, the SET TERM verb is not properly screened against executing in detached or network jobs. For example, let's say you did: $ Dir VAXEN:: and it aborts with an error saying "Path to network object lost." In that case, wait for the server process on the remote node to exit, and then look at the NETSERVER.LOG file to see where in the DCL script the thing died at. Usually, something on the order of: $ IF (F$MODE() .EQS. "INTERACTIVE") $ THEN $ SET CONTROL=(T,Y) $ SET TERM /LINE/INSERT/INQUIRE $ ENDIF $! is sufficient (%^/) (<-- My "don't-quit-your-day-job" face. Sheesh..) >#Any help would be appreciated. >#Pete ># A tree is known by the fruit that it bears. Even if it means having to endure the reproach of a few blowhards, -please- continue to ask us questions. There's lots of us who are genuinely interested in using our skills to help others via the Internet. Besides, in time you will learn who the truely-gifted are, as opposed to those who can only parrot from the Online Doc Set (and who have to hide behind their flaming because they have nothing else to contribute). >#-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v^-v-^ >#Pete Sabotka, Meteorology Dept. sabotkap@woods.ulowell.edu >#University of Massachusetts - Lowell "I lost a buttonhole..." S. Wright >#^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v-^-v^-v-^ > > Ehud > >-- >Ehud Gavron (EG76) >gavron@vesta.sunquest.com > -- Bill Laut Internet: laut@alien.gici.com Gull Island Consultants, Inc. Phone: (616) 780-3321 Muskegon, MI 49440 >> "Usual disclaimers, apply within" << "Your majesty, I have a message from God for you." -- Judges 3:20