From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 22-JAN-1991 21:35:05.20
To:	MRGATE::"ARISIA::EVERHART"
CC:	
Subj:	Re: Multiple [sysexe] areas?DIR/NEW

Received:  by crdgw1.ge.com (5.57/GE 1.80)
	 id AA00786; Tue, 22 Jan 91 21:25:53 EST
Received: From UCBVAX.BERKELEY.EDU by CRVAX.SRI.COM with TCP; Tue, 22 JAN 91 17:35:58 PST
Received: by ucbvax.Berkeley.EDU (5.63/1.42)
	id AA17248; Tue, 22 Jan 91 17:22:38 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 Jan 91 13:18:02 GMT
From: sdd.hp.com!news.cs.indiana.edu!bsu-cs!bsu-ucs!00prneubauer@ucsd.edu  (Paul Neubauer)
Organization: Ball State University, Muncie, In - Univ. Computing Svc's
Subject: Re: Multiple [sysexe] areas?DIR/NEW
Message-Id: <56362@bsu-ucs.uucp>
References: <00943031.246C86C0@SECS.ucsc.edu>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <00943031.246C86C0@SECS.ucsc.edu>, wipke@SECS.ucsc.edu 
 (W. Todd Wipke) writes:
> Is it possible to have a satellite vaxstation 3100 boot off its own
> disk (102 meg) and yet obtain some installed application software from
> the cluster server sys$common:[sysexe]?  

Yes, absolutely.

>Perhaps by adding to the
> sys$system logical the other system area in which to look?
> The problem is that the vaxstation disk is too small for all the 
> system software.  By having at least some of the software locally, I
> figure it will increase efficiency and lower load on cluster server.
> What is the wisdom of the netlanders?  Thanks.

I agree (for what it's worth) that accessing some software locally SHOULD be
more efficient, though I have not actually run tests (and am not even sure HOW
I would control such tests).  I am not on the right account right now to simply
include examples into this file, so beware that the code I am posting is from
memory, not tested working DCL.  That said, the basic strategy runs as follows:

given 
     -	a VAXstation clustered, but booting off its own disk (assume DKA200) 
	(actually, it can alternatively boot off the cluster disks and still 
	use a lot of the more common stuff off its own disk, but that is a 
	little trickier); 
     -	a cluster of other VAXen (of whatever sizes), at least one of which
	boots from a larger disk (call it $1$dua100)

in SYSTARTUP_V5.COM:

$ define/system/exec local_common dka200:[vms$common.]/trans=(term,conc)
$ define/system/exec clust_common $1$dua100:[vms$common.]/trans=(term,conc)
$ define/system/exec sys$common   local_common,clust_common

then, since SYS$SYSTEM is defined as SYS$SYSROOT:[SYSEXE] (unless you have some
other wierd setups, which is all too likely :-() this should get you to the
right place for anything looking for SYS$SYSTEM.  Note that I used
[VMS$COMMON.], rather than [SYS0.SYSCOMMON.], which _probably_ refers to the
same place.  You may need to make adjustments for your system. I have defined
several local_* and clust_* logicals of this sort to make life simpler, though
strictly speaking, you could just do the 3rd line with phycical names and
eliminate the first two.

You should then be able to:

$ install add/whatever_qualifiers clust_common:[sysexe]fortran !or whatever

Note also, that it is not strictly necessary to INSTALL the fortran compiler or
most things as long as you have a symbol set up or an entry in your DCL tables.
You really only need to INSTALL them if they need to have privs or some other
attribute (e.g., be shared images).  You can use many images in sys$system with
NO other preparation beyond what I have already listed.  Of course, you can
also get fancier, as the spirit moves you.

Good luck.

========
Paul Neubauer	neubauer@bsu-cs.bsu.edu         00prneubauer@bsu-ucs.bsu.edu
                neubauer@bsu-cs.UUCP            00prneubauer@bsu-ucs.UUCP
                                                00PRNEUBAUER@BSUVAX1.BITNET