[comp.os.vms] SETUP

hamm@BIOVAX.RUTGERS.EDU (04/25/87)

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

------

CHRIS@ENGVAX.SCG.HAC.COM.UUCP (04/27/87)

>Who else has implementations of SETUP/PREPARE, and how do they differ from
>these two?

     We do...  Though after reading about the way that other people have this
type of utility defined there has been some serious thought about redoing the
way that it works!

     Our's is called SETUP, so in SYLOGIN.COM the DCL symbol SETUP is set to
@PUB:SETUP.  Currently SETUP is one big long command procedure with a bunch of
labels.  When a user issues a command like:

$ SETUP TEX

The DCL code fragment that they execute in SETUP looks like:

$       on warning then goto No_Such_Setup
$       if p1 .eqs. "" then goto Show_Available_Setups
$       goto 'p1'
              :
              :
              :
$ TeX:
$ LaTeX:
$       @TeX_Root:[Local]TexSetup
$       if f$mode() .eqs. "BATCH" THEN goto Done
$       define/user sys$input sys$command
$       News/Directory TeX
$       goto Done

     Note that this allows to point different names for the same setup at the
same procedure.  The problem with this approach is that even with abbreviated
sections for each command, the SETUP command procedure quickly gets *very*
long.  Ours is 407 lines, and growing.  It also contains product definitions
for *every* system that we manage, so portions are never accessed on some
systems.

     Personally I like the idea of having a short, simple command procedure
that attempts to execute the first parameter passed to it.  If you're tricky,
you put the setup command files in a directory pointed to by a logical name
that is a list.  Then you can put your "normal" command files in the
"every-system" directory, and the "local" command files in the "local"
directory and let the system look in the local directory first and the
every-system directory if it can't execute anything in the local directory. In
some ways it's easier to manage, commands are trivial to add and remove simply
by adding files to or deleting them from your system directory, though you do
end up with a whole mess of little tiny command procedures cluttering your
setup directory(s).

     I'm not quite sure what to say about the issue of speed...  The approach
outlined above will be quicker than one big long command procedure most of the
time, but I really have no data or feel for how long it takes to add another
command procedure onto the stack.  I'm also not quite certain how one would get
a program to be able to execute the setup command procedure *in the context of
the current process* (it's easy enough to spawn of a command that executes the
command file though).  I don't believe that a parent processes symbols or
Command Language Definitions can be modified from a subprocess.

     More ideas, thoughts, and musings on this subject are welcomed!  I'd love
to hear how other people deal with this issue.

-- Chris Yoder          UUCP -- {allegra or ihnp4}!scgvaxd!engvax!chris
   Hughes Aircraft  Internet -- chris%engvax.scg.hac.com@ymir.bitnet
        Company         ARPA -- chris%engvax.scg.hac.com@oberon.usc.edu