Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!mit-eddie!uw-beaver!tektronix!decvax!ucbvax!BIOVAX.RUTGERS.EDU!hamm From: hamm@BIOVAX.RUTGERS.EDU Newsgroups: comp.os.vms Subject: RE: SETUP Message-ID: <8704260926.AA01765@ucbvax.Berkeley.EDU> Date: Sat, 25-Apr-87 00:02:00 EDT Article-I.D.: ucbvax.8704260926.AA01765 Posted: Sat Apr 25 00:02:00 1987 Date-Received: Sun, 26-Apr-87 23:21:37 EDT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Distribution: world Organization: The ARPA Internet Lines: 56 Bill Costa at UNH describes their SETUP utility. I found this interesting because it's nearly identical to a utility we implemented at the European Molecular Biology Lab (EMBL), for all the same reasons. (Actually, we borrowed the idea from someone at a British University - wonder how many other implementations there are?) Our version was called PREPARE (usually PREP). We did go through a couple of evolution cycles on the thing, though: By the way, the SETUP program is dirt simple. Right now it is simply a command procedure that, when asked to 'setup' the program FRED, will search a particular system directory for the file "FRED.SETUP". If the file does NOT exist, the user is told that there is no such command as FRED, and that they should check their spelling. If FRED.SETUP is found, it is simply "@'d". In other words, FRED.SETUP is itself a command procedure that will do WHATEVER IT TAKES to make FRED a command for the user. (For some programs, it may mean defining a dozen or so logicals and inserting the command into their DCL command table. For others, it may be as simple as defining a symbol; "FRED :== @UTL:FRED.COM"). The first change was that we wrote a program instead of a command procedure, because people usually put PREPAREs in their login.coms and got tired of waiting for them. We then had a file (called a "prepare dictionary") which contained a single-line command for each "prepare environment". Usually these were things like "@some.com", but they were also allowed to be SET COMMANDs or single definitions of some sort. Since the things were not required to sit in one directory, this also gave us a mechanism to provide global access to things the systems group were not maintaining - we'd just point the prepare command at some user's setup procedure, and let him/her do all the work. This worked well, but the list of environments grew, and the thing was again too slow. Finally we made the dictionary file indexed, and wrote a small PREPUTIL to add/remove things from it. This was less convenient than having just a text file, but sure was faster. As far as I know, this is the version they're currently running. By the way, all this "we" stuff I keep saying was mainly Roy Omond - I just watched and made helpful noises ("It's too slow, Roy!"). Whatever the implementation, I certainly agree with Bill that this is an ideal way to avoid defining everything for everyone. It also provides a lazy way out of the problem which occurs when two third-party packages define the same symbol differently. You just tell people to prepare only one of them at a time. (Beats workin'!) Who else has implementations of SETUP/PREPARE, and how do they differ from these two? Greg Hamm Director, Rutgers Molecular Biology Computing Lab hamm@biovax.rutgers.edu hamm@biovax.bitnet ------