NELSONJE@VTVAX5.BITNET (Where am I?) (12/08/87)
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.bitnetjdc@beach.cis.ufl.edu (Jeff Capehart) (12/11/87)
In article <8712080924.AA13169@ucbvax.Berkeley.EDU> NELSONJE@VTVAX5.BITNET (Where am I?) writes: > >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 You may be able to create an alias, but LNM$JOB is an [exec] mode logical name and there is no way a user can override this if the translations are done properly. Therefore it is silly to say that the user might redefine what LNM$JOB is supposed to be. >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. Again, how would the user delete [exec] mode logical names? Anyways, I am not really worried about my own job table. I have a situation where user1 creates a mailbox to converse with user2, send back stats and that sort of info. The logical name for the mailbox is put in LNM$JOB for user1. User2 would like to translate the logical name so it can open the proper mailbox. User1 sets an acl on his job table so that User2 can read from it. User2 now has access but has no idea what the name of the table is. Aside from dumping output from "show logical" to a file, since I could just as easily dump the mailbox name to a file, how is user2 supposed to figure out what the name of user1's job table is? -- Jeff Capehart Internet: micronaut%oak.decnet@pine.circa.ufl.edu University of Florida UUCP: ..!ihnp4!codas!ufcsv!beach.cis.ufl.edu!jdc
MCGUIRE@GRIN2.BITNET (12/15/87)
> Date: 11 Dec 87 03:09:58 GMT > From: Jeff Capehart <BEACH.CIS.UFL.EDU!JDC@BIKINI.CIS.UFL.EDU> > Subject: Re: Definition of LNM$JOB > > You may be able to create an alias, but LNM$JOB is an [exec] mode logical > name and there is no way a user can override this if the translations are > done properly. Therefore it is silly to say that the user might redefine > what LNM$JOB is supposed to be. On the contrary: The executive mode logical name need not be deleted at all. The user can define LNM$JOB in supervisor mode. The result is that LNM$JOB is defined twice, once flagged EXEC and once flagged SUPER. Supervisor mode logical names are translated before executive mode ones. Of course, you can tell the $TRNLNM translation service to start the search with executive mode logical names, skipping the redefined name. The image activator is particularly careful to do this when activating images installed with privilege. I realize that the above discussion does not relate to your problem of finding another user's job table, but I thought a point of confusion should be cleared up. Good luck! Ed