Newsgroups: comp.parallel.pvm
From: norman@cs.toronto.edu (Norman Wilson)
Subject: Papering over PVM startup problems
Organization: University of Toronto
Date: 23 Aug 94 17:56:34 GMT
Message-ID: <94Aug23.134717edt.48151@neat.cs.toronto.edu>

Some people may be interested in how I keep people from having to worry
about $PVM_ROOT on our systems.  I came up with this scheme because I'm
an inveterate sh user, but it seems to make life easier for everyone else
as well.

We have a central PVM_ROOT in /usr/local/lib/pvm3, but people are not
expected to access that directly; instead, they run /usr/local/bin/pvm
or /usr/local/bin/pvmd3.  Both of these are shell scripts of the form
	#!/bin/sh
	# quick and dirty pick-the-right-architecture interface to pvm
	case "$PVM_ROOT" in "")
		PVM_ROOT=/usr/local/lib/pvm3
		PVM_DPATH=pvm3/lib/pvmd
		export PVM_DPATH
	esac
	PVM_ARCH=${PVM_ARCH-`$PVM_ROOT/lib/pvmgetarch`}
	export PVM_ROOT PVM_ARCH
	case "x$PVM_ARCH" in
	x)	echo >&2 $0: cannot find architecture
		exit 1
		;;
	esac
	exec $PVM_ROOT/lib/$PVM_ARCH/pvm $*
i.e.
- if $PVM_ROOT isn't set, point it at our central copy.  (If the user
has already set $PVM_ROOT, it's up to them to get it right.)
- if we had to set $PVM_ROOT, also set $PVM_DPATH; if this variable
is set, the master pvmd uses its value as the argument to rsh when
invoking a new daemon.

The rest of the script is just the obvious: get the architecture from
pvmgetarch, and use that to find the proper binary for this system.

Notice the value of $PVM_DPATH: it is assumed that pvmd is in the
user's own pvm3 directory.  (The working directory of a command invoked
by rsh is the user's home directory; hence the relative path.  With
appropriate quoting, one might stick $HOME in front.)  I tell people to
run /usr/local/bin/pvm3setup before using PVM for the first time:
	#!/bin/sh
	# set up user's pvm3 directory
	# pointing library stuff at the central copy
	PVM_ROOT=/usr/local/lib/pvm3
	PVM_ARCH=`$PVM_ROOT/lib/pvmgetarch`
	case "$PVM_ARCH" in
	"")	echo >&2 $0: cannot get architecture
		exit 1
		;;
	esac
	cd
	mkdir pvm3 pvm3/bin pvm3/bin/$PVM_ARCH
	rm -f pvm3/lib; ln -s $PVM_ROOT/lib pvm3/lib
Thus they end up with a symlink pointing to the central copy.

This runs pvmd (the official copy, not /usr/local/bin/pvmd3) with neither
$PVM_ROOT nor $PVM_DPATH set, but that's OK; the stock $PVM_ROOT/lib/pvmd
can figure out $PVM_ROOT on its own, and only the master daemon (the one
started first, via the console or by running pvmd3 directly) uses $PVM_DPATH.

So if the user doesn't set $PVM_ROOT at all, it all just works.  If the
user uses csh and sets $PVM_ROOT in his .cshrc everywhere, it still works
(PVM_DPATH is never set).  If the user sets PVM_ROOT and starts the master
daemon, then tries to start pvmd on a system where his shell is sh (or he
otherwise hasn't set PVM_ROOT), things will fail, but they would have
failed even without my scheme.

If someone starts a master pvmd on one of my systems (and doesn't set
PVM_ROOT, and so uses my scheme) and tries to add an outside system, it
will fail unless pvm3/lib/pvmd on the outside system is a valid name for
the daemon--likely if the user installed PVM there himself, unlikely if
there's a central copy.  It will fail even if he sets $PVM_ROOT, which
is annoying.  It hasn't happened yet, which isn't much of an excuse.

Why depend on the home directory--why not set PVM_DPATH to
/usr/local/lib/pvm3/lib/pvmd?  Because that makes it even harder to
include outside users--with an absolute path, one must somehow get the
remote system administrator to make /usr/local/lib/pvm3 the right thing,
rather than just making a link in one's own directory.

Norman Wilson
University of Toronto
norman@utirc.utoronto.ca

