NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/os/vms/20276

Internet Message Format | 1993-01-04 | 10.9 KB

Path: sparky!uunet!elroy.jpl.nasa.gov!ames!purdue!vortex.gici.com!alien.gici.com!laut
Newsgroups: comp.os.vms
Subject: Re: TT_AccPorNam field remains null on a SHOW USERS output ?
Message-ID: <[e-mail]>
From: [e-mail] (Bill Laut)
Date: 4 Jan 93 04:41:18 EDT
References: <[e-mail]> <[e-mail]>
Organization: Gull Island Consultants, Inc.
Nntp-Posting-Host: alien.gici.com
Lines: 255

In article <[e-mail]>, Ehud writes:
>In article <[e-mail]>, [e-mail] 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.           [e-mail]
>#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)
>[e-mail]
>

--
Bill Laut            Internet:  [e-mail]
Gull Island Consultants, Inc.    Phone:     [phone]
Muskegon, MI  49440        >> "Usual disclaimers, apply within" <<

"Your majesty, I have a message from God for you."    -- Judges 3:20