Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!VTVAX5.BITNET!NELSONJE
From: NELSONJE@VTVAX5.BITNET (Where am I?)
Newsgroups: comp.os.vms
Subject: Definition of LNM$JOB
Message-ID: <8712080924.AA13169@ucbvax.Berkeley.EDU>
Date: Tue, 8-Dec-87 04:25:00 EST
Article-I.D.: ucbvax.8712080924.AA13169
Posted: Tue Dec  8 04:25:00 1987
Date-Received: Sun, 13-Dec-87 10:31:56 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 59

In INFO-VAX, Jeff Capeheart (micronaut%oak.decnet@pine.circa.ufl.edu) inquires
about the name of the job logical name table.  The name for this table is
LNM$JOB, which itself is a logical name that exists in the LNM$PROCESS_DIRECTORY
table.  In other words,

$ show logical/table=lnm$process_directory lnm$job

will return the name of the logical name table.  It turns out that this
logical name translates to something of the form "LNM$JOB_xxxxxxxx",
where "xxxxxxxx" is the address of the Job Information Block (JIB) internal
VMS data stucture.  I just checked, and there doesn't appear to be a way to
find the JIB address using $GETJPI directly.  However, you can get it by
referencing the global symbol CTL$GL_PCB (defined in SYS$SYSTEM:SYS.STB) with
offset PCB$L_JIB.

Now that you know, you should forget it.  There are several reasons why.
First, because users (like me) may decide that they want to redefine LNM$JOB.
Note that it doesn't take any special privileges to create a logical name
table in the LNM$PROCESS_DIRECTORY table;  I do it all the time, and stick my
mail aliases in the table.  The table (JEN$MAIL_NAMES) is search-listed with
the former definition of LNM$JOB thusly:

$ define/table=lnm$process_directory lnm$job -
        'f$trnlnm("lnm$job","lnm$process_directory")', JEN$MAIL_NAMES

Note that I just gave you the lexical function (which corresponds to the
system service) that returns the information for your job.

Second, because VMS may decide to change what LNM$JOB is defined as, and you
don't want your program breaking because it depends on LNM$JOB being defined
in a certain way.

Finally, because your program may be making totally invalid assumptions about
a user process.  Recall that VMS totally rewrote the logical name services in
order to make them more flexible.  However, VMS also had to make sure the old
stuff still worked like before.  Therefore, they invented some logical names:
LNM$FILE_DEV, LNM$DCL_LOGICAL, and more.  Check out the logical name
definitions in the LNM$SYSTEM_DIRECTORY table.  Like the definition of
LNM$JOB, a user may define his or her own LNM$FILE_DEV and place it in
LNM$PROCESS_DIRECTORY, and it overrides the definition in LNM$SYSTEM_DIRECTORY
(maybe!  This too, depends on a logical, LNM$DIRECTORIES).

The point is this:  the user has much more control over his logical name
tables, and which ones get searched.  You shouldn't depend on a specific
definition of LNM$JOB because you might be wrong.  In fact, it's conceivable
that the user decides *never* to include LNM$JOB in LNM$FILE_DEV, etc.

I recommend that you stick with the logical name LNM$JOB, and not try to
translate it -- let the system worry about its definition for you.  If you are
worried about the user redefining LNM$FILE_DEV, then you have a larger
programming task ahead of you.

By the way, an entire chapter is devoted to logical names in the System
Services Reference Manual: chapter 6.

--Jeff E. Nelson
Virginia Polytechnic Institute and State University

Internet/Bitnet:  nelsonje@vtvax5.bitnet