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