From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 15-NOV-1992 15:19 15-NOV-1992 15:19:00.00
To:	info-vax@kl.sri.com
CC:	
Subj:	Re: Plans for mixed Alpha/VAX cluster with common system disk?


In article <1992Nov13.100832.3777@dxcern.cern.ch>, julian@vscn08.cern.ch (Julian James Bunn) writes:

|>What worries me more about a mixed architecture VAX/Alpha VMS Cluster is
|>how the poor innocent users are going to sort out the confusion between
|>VAX and Alpha executables. I assume DEC will provide solutions for system
|>logical name tables etc etc for MAVCs, but I bet they wont for the default
|>login directories. The particular problem I see is if the user logs in to
|>the Alpha node in the Cluster one day, re-compiles and links all his source
|>files, then logs in to the VAX node in the Cluster the next day (why should
|>he care what architecture he happens to get?) and wonders why he gets 
|>
|>Image file VXCRNA::DISK$C:[JULIAN]COUNTER.EXE;20
|>Image is not an OpenVMS Alpha image

If only it were that clean; the actual message is:

$ r TOOLS$DISK:[TOOLS$COMMON.SYSEXE]SET_TERM_INQUIRE_ALPHA_32.EXE;1
%DCL-W-ACTIMAGE, error activating image TOOLS$DISK:[TOOLS$COMMON.SYSEXE]SET_TERM
_INQUIRE_ALPHA_32.EXE;1
-CLI-E-IMGNAME, image file $255$DUA118:[TOOLS$COMMON.SYSEXE]SET_TERM_INQUIRE_ALP
HA_32.EXE;1
-IMGACT-F-IMG_SIZ, image header descriptor length is invalid

|>
|>Perhaps one could define a LINK symbol in sylogin that, for the Alpha
|>node, directs the .EXE file into a subdirectory [.ALPHA_EXE] ? But this is
|>messy, and probably not what the user wants. Defining different directory
|>trees depending on the node type is no good either, as it defeats one 
|>advantage of a cluster, which is to share the data. Unless ... there was some
|>way of linking the source files together, and keeping the excutables and object
|>files separate. 
|>
|>Has anybody got any bright ideas ?

What you suggest is one idea, but as you suggest there are problems with that.
What we have been doing is appending the architecture to the image name and
then defining a logical for the architecture which is then used to construct
the image name. A la

$    if f$getsyi("hw_model") .lt. 1023
$    then
$       define_sys sys$arch vax
$       sys$arch="vax"
$    else
$       define_sys sys$arch alpha_32
$       sys$arch="alpha_32"
$    endif
$define_sys set_term_inquire -
        tools$junk:[tools$common.sysexe]set_term_inquire_'sys$arch
$install add set_term_inquire/open
$define_sys jpi$jpi tools$junk_2:[tools$common.sysexe]jpi_'sys$arch
$install add jpi$jpi/open

This issue has been debated, at time hotly debated, within DEC on a number of
occasions and the conclusion is that there is no single solution.  The current
solution can be argued as the best for the following reasons:
	1. many systems are not part of clusters
	2. most users don't have their own executables
	3. users who do have their own executables are often programmers used
	   to dealing with such problems
	4. in new installations, which will hopefully dominate in a few years,
	   this won't be a problem
	5. in most cases executables are kept in sys$system which is
	   architecture specific
	6. it doesn't require as many changes in the documentation in VMS books
	   and lots of other books from both DEC and software vendors and
	   customers
	7. when VAX systems are no longer around (say a decade from now), no
	   one will care.  (How many people care about the fact that RSX tasks
	   changed from .TSK to .EXE when moved to VMS?  How many people even
	   know what a task, or even RSX is?)

Anyway, over the next number of months, you can review the way that you handle
your local procedures and consider your options; you can even start implementing
it now.  Note that while there is a new SYI code that indicates architecture,
this is not supported on any but the most recent versions of VMS.  The checking
to see if the hardware model is less than 1024 will identify VAX systems.

(Actually, if you participate in a field test or seed program, some Alpha 
systems have been had a hardware model code of 0; therefore a more complete
check is the following which works with baselevels since FT3:

$ architecture = f$edit(f$getsyi("node_hwtype"), "collapse")
$ if (architecture .eqs. "ALPH") .or. (architecture .eqs. "EVAX")
$ then
$       define/system/nolog sys$arch alpha_32
$       sys$arch="alpha_32"
$ else
$    if f$getsyi("hw_model") .lt. 1023
$    then
$       define_sys sys$arch vax
$       sys$arch="vax"
$    else
$       define_sys sys$arch alpha_32
$       sys$arch="alpha_32"
$    endif
$ endif

As with just about anything VMS, there is even debate about how you should
make the check as well, including doing thing like set noon, define/user
sys$output nl:, define/user sys$error nl:, and then arch=f$getsyi("archflag")
which will be 2 if its an Alpha system and a 0 or 1 if a VAX system.)

mulp
DEC, CVG cluster buster