Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-unix!hplabs!ucbvax!USC-OBERON.ARPA!TLI%Sargas From: TLI%Sargas@USC-OBERON.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: Are custom HELP libraries a good idea? Message-ID: Date: Fri, 27-Mar-87 11:27:23 EST Article-I.D.: Posted: Fri Mar 27 11:27:23 1987 Date-Received: Sun, 29-Mar-87 09:08:09 EST References: Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 32 Approved: info-vax@sri-kl.arpa What I'm thinking of doing is turning the default around, i.e., putting the local stuff in as the root library, and letting the VMS stuff be accessible with "@". I would of course define HLP$LIBRARY, so that if someone said "HELP COPY", they'd still get an answer. But if they said "HELP", they'd get a much smaller list of stuff that makes sense to them. Since everything would be accomplished by logical name definition, it would seem an easy solution to maintain though VMS updates, etc. But somehow, it feels like a bad idea. It is. During upgrades, VMS patches HELPLIB.HLB. We use the secondary libraries here for our local mods, and it seems to work reasonably well. Yes, it can be somewhat ugly, but you needn't type the "@LOCAL" portion if the key is not in the main library. While I'm at it, I'd like to complain about third-party vendors whose installation kits directly patch HELPLIB.HLB. This tends to cause system managers lots of pain the next time the system goes through a major upgrade. DEC gives you a clean copy of HELPLIB, and you now have to go through and remove the third party modules.... This is pretty silly. The "correct" thing to do would be to let the manager specify the library to add onto. Thus, if you want a "true" top level command you can get it, but for those of us with segmented, local systems, none of the standard system files get modified. Cheers, Tony ;-) -------