Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbatt!ucbvax!ENGVAX.SCG.HAC.COM!CHRIS
From: CHRIS@ENGVAX.SCG.HAC.COM.UUCP
Newsgroups: comp.os.vms
Subject: RE: SETUP
Message-ID: <8704281204.AA17604@ucbvax.Berkeley.EDU>
Date: Mon, 27-Apr-87 11:54:00 EDT
Article-I.D.: ucbvax.8704281204.AA17604
Posted: Mon Apr 27 11:54:00 1987
Date-Received: Wed, 29-Apr-87 05:58:07 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 63

>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