Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!cmcl2!beta!unm-la!unmvax!hi!hc!ames!ucbcad!ucbvax!CRUXNMC.BITNET!POSTMASTER From: POSTMASTER@CRUXNMC.BITNET Newsgroups: comp.os.vms Subject: (none) Message-ID: <8707011935.AA05965@ucbvax.Berkeley.EDU> Date: Wed, 1-Jul-87 15:35:14 EDT Article-I.D.: ucbvax.8707011935.AA05965 Posted: Wed Jul 1 15:35:14 1987 Date-Received: Fri, 3-Jul-87 03:16:07 EDT Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 181 From CRUXNMC.bitnet!POSTMASTER Mon Jun 29 18:08:43 1987 remote from mcvax Received: by mcvax.cwi.nl; Mon, 29 Jun 87 18:08:43 +0200 (MET) From: mcvax!CRUXNMC.bitnet!POSTMASTER Received: from mint.cern (mint) by cernvax.UUCP (4.12/4.7) id AA09445; Sat, 27 Jun 87 20:06:38 +0200 Received: by mint.cern (cernvax) (4.12/3.14) id AA01690; Sat, 27 Jun 87 20:04:52 +0200 Message-Id: <8706271804.AA01690@mint.cern> Received: by cernvax Sat Jun 27 20:04:48 from POSTMAST@CRUXNMC.BITNET for info-vax@cernvax via rscs. X-Bitnet-Sender: General Delivery Date: Sat, 27 Jun 87 20:03 N Original_From: Jnet%"W_COSTA@UNHH" Comments: This is gatewayed mail. Warning: Mail may not necessarily be returnable through this path. Subject: LNK$LIBRARY summary (by popular request). To: sri-kl.arpa!info-vax Received: From CEARN(MAILER) by CRUXNMC with RSCS id 2723 for RSC@CRUXNMC; Sat, 27 Jun 87 20:03 N Received: by CEARN (Mailer X1.24) id 2716; Sat, 27 Jun 87 20:03:40 GVA Date: Sat, 27 Jun 87 13:26 EDT Reply-To: "Bill Costa, Academic Services Group" Sender: Info Vax From: "Bill Costa, Academic Services Group" Subject: LNK$LIBRARY summary (by popular request). Comments: To: To: ROBERT SCHUMACHER > From: Ian J. MacPhedran, Eng. Applications, DCS > > Bill; > You may as well post it. I'd like to see it, and I'm sure you'll > get better than 10 replies. > Ian. Ian was right... Here's everything you could possibly want to know about the logicals LNK$LIBRARY and HLP$LIBRARY. (And probably a whole lot more!) While I have tried to make sure that this information is accurate by doing several tests on two different systems, it's still possible I may have overlooked something or gotten things muddled. If you find this is so - please let me know. (In other words this is a disclaimer!) At least two VMS utilities make use of logical name "lists" of the form: xxx$LIBRARY xxx$LIBRARY_1 xxx$LIBRARY_2 : : xxx$LIBRARY_99 This style of logical naming is exploted by the VMS LINK (LNK$LIBRARY) and HELP (HLP$LIBRARY) commands. Basically each utility will use a set of default (system) files to do their work, as well as any that have been explicitly specified by the user. However, they then will automatically search the logical name tables for logical names of the above form. If such names exist, the files that these logicals point to will automatically take part in the current processing being done by the utility. The logical name tables LNM$PROCESS, LNM$GROUP and LNM$SYSTEM are searched in that order (but see the note below). Using the linker as an example, if the logical LNK$LIBRARY is found in one of the above tables, the file it points to is used as part of the linking process. From that same table, the existence of LNK$LIBRARY_1, LNK$LIBRARY_2, etc. are also checked and used in turn. After exhausting the logicals discovered in one table, the next logical table is searched. It is important that the logical name xxx$LIBRARY be the first name in the sequence for any table, and that the sequence of numbers be unbroken. For example, given the following definitions: PROCESS GROUP SYSTEM --------------------- -------------------- ------------------- LNK$LIBRARY = BERRY LNK$LIBRARY_1 = PAUL LNK$LIBRARY = JIM LNK$LIBRARY_1 = MARY LNK$LIBRARY_2 = SAUL LNK$LIBRARY_1 = TIM LNK$LIBRARY_2 = GERRY LNK$LIBRARY_2 = KIM LNK$LIBRARY_4 = CARY LNK$LIBRARY_5 = HARRY the library files will be searched in the order of BERRY, MARY, GERRY, JIM, TIM and KIM. The files CARY and HARRY are never referenced since the logical name LNK$LIBRARY_3 was not defined in the LNM$PROCESS table. Likewise PAUL and SAUL get skipped because there is no LNK$LIBRARY logical name in the LNM$GROUP table. The behaviour of LINK and HELP are a little different where the use of these logicals are concerned. First, it is a good practice to make sure that the equivalence string of the logical be a complete file specification; if you leave information out, the defaults used by each utility are different. For example, LINK will use the user's current default location if the disk and/or directory are not specified as part of the logical name's equivalent string. But for HELP, the location specified by the logical name SYS$HELP is used instead. (In either case, full DECNET specifications are allowed and it is possible for a help or object library to be used from across the net, although it tends to be a little slow.) The second difference has to do with what the utility does if the file specified cannot be found. LINK will complain - echoing the name of the file it was trying to locate. HELP, on the other hand, simply keeps quiet - as if nothing was wrong. For example, if you define the logical name: $ DEFINE HLP$LIBRARY FRED.HLB and this file is located in your own directory, it will appear that HELP is ignoring this logical name definition. (Remember - it's looking for SYS$HELP:FRED.HLB!) Of course: $ DEFINE HLP$LIBRARY $DISK1:[J_USER]FRED.HLB should work just fine. Two final picayune details should be noted, although I doubt that they'll effect virtually anyone. According to documentation supplied for the HELP and LINK commands, the tables are searched in the order of PROCESS, GROUP then SYSTEM. But in point of fact, the JOB table will also be searched if, and only if, the xxx$LIBRARY logical is not defined in the PROCESS table. And for those of you who would like to change the order of this searching, it does not appear that playing with the definition of LNM$FILE_DEV in the LNM$PROCESS_DIRECTORY table has any effect. In closing, the following command procedure illustrates how additional logicals of this type can be added to end of the list of such logicals in the user's process table. (Note that no effort is made to guard against duplication of equivalent strings themselves, although this feature would not be hard to add if necessary. ## ## ## ## +----------------------------------------------------- ## ### ## ## ! Bill Costa PHONE: (603) 862-3056 ## #### ## ## ! UNH Computer Services BITNET: W_COSTA@UNHH ## ## ## ######## ! Kingsbury Hall UUCP: ...decvax!unh!wfc ## ## #### ## ! Durham, NH 03824 ## ## ### ## ! ####### ## ## +----------------------------------------------------- ---[cut here]--------------------------------------------------------- $!============================================================================ $! $! Adds three more default link libraries to the user's PROCESS table. $! (Does not guard against duplicate equivalence strings being added.) $! $ $ Make_LName: Lib_Name := LNK$LIBRARY $ Lib_Count = 0 $ Lib_Logical = Lib_Name $ $ Search_Loop: IF (F$TRNLN(Lib_Logical,"LNM$PROCESS") .EQS. "") - THEN GOTO Start_Adding $ ! ELSE Keep looking for an empty slot. $ Lib_Count = Lib_Count + 1 $ Lib_Logical = Lib_Name + "_" + F$STRING(Lib_Count) $ GOTO Search_Loop $ $ Start_Adding: ! +-----------------------------------+ $ ! |Add each new library you want to be| $ ! |defined here. Be sure to increment| $ ! |the Lib_Count between each. | $ ! +-----------------------------------+ $ $ DEFINE 'Lib_Logical' DISK:[DIRECTORY]FIRST.OBJ $ $ Lib_Count = Lib_Count + 1 $ Lib_Logical = Lib_Name + "_" + F$STRING(Lib_Count) $ DEFINE 'Lib_Logical' DISK:[DIRECTORY]SECOND.OBJ $ $ Lib_Count = Lib_Count + 1 $ Lib_Logical = Lib_Name + "_" + F$STRING(Lib_Count) $ DEFINE 'Lib_Logical' DISK:[DIRECTORY]THIRD.OBJ $ $ SHOW LOGICAL 'Lib_Name'* $ EXIT