Just when you thought you had it all figured out, we go and change everything.

What has been changed:

Each user on all the systems now has a unique UIC (User Identification Code)
which makes the cluster software officially released. You no longer need to use
DECnet to copy files back and forth between systems. You shouldn't even need to
copy files back and forth at all (except for backup purposes). For those of you
who have directories on other systems, you can access your files (for read and
write) from any system by using the device names of node$USERDISK (userdisk(s))
or node$SYSDEVICE (system disk) for example: 

	$ DIR KIM$USERDISK:[FRED]

Please avoid using the old (DECNET) method with KIM::, CHARM::, etc. We'd all
appreciate it and so will you. I suggest that you use logical names to point to
the various disks on which you may have directories. I think that you'll find
the cluster much more convenient especially with PRINT, IMI and DIO procedures. 

The next thing we changed was the way the ques work on Kim and Charm (Sandy will
soon be joining this group). They operate from a common job que manager file so
each "knows" about the other's ques (both print and batch). Using the cluster
software we were able to make the two line printers spool from a common
SYS$PRINT. The consequence of this is that the items you asked to be printed on
Kim for example, may in fact be printed on Charm's line printer and visa-versa.
So, look in the baskets of either printer for your printout. At the moment, the
batch ques work the same as they always have. You can still reference them as
SYS$BATCH, etc. but they are really named KIM$BATCH or CHARM$BATCH, etc. As for
the letter quality printers, you can use the PRINT command from either Kim or
Charm to either the NEC spinwriter or the Diablo 630 in the common area:

	$ PRINT/QUE=LQ0	your_file	!NEC spinwriter
	$ PRINT/QUE=RAINS$LQ your_file	!Diablo

What will be changed: 

I'm requesting input from everyone before I make the next major change. If you
have some serious objections, then maybe I won't do it this way: 

I plan to combine all the user authorization files of all the systems into one
common file. After this is done, all users will have an account on ALL the
systems, however, each user's account will point to a single directory located
on what will be called his/her "home" system. For example, my home system would
be Kim, so which ever system I logged into, my default directory would be
KIM$USERDISK:[SHEPPERD] so the LOGIN.COM in that directory would be run at
login. Some one else's home directory may be on a different system. Those of you
with accounts on multiple systems will have to specify (if it isn't obvious to
me) which one they want as their home directory. There are some benefits to this
procedure at present, namely the IMI and DIO could be run by anyone without
having to have accounts on Kim and Charm nor would they have to copy files
around or change defaults or whatever. You would no longer need node names on
the mail distributions and indeed you should NOT put node names on the dist
lists, since everyone will have only one MAIL file (in or off of your home
directory) and all systems will know about all the users. This would make
sending mail quite a bit faster (probably almost as quick as sending to someone
on the same node as you). Kim and Charm's batch queues could be combined so that
batch jobs would be scheduled alternately between them to better even the load.
Techincally you could switch systems (via a SET HOST) if you found the one you
were on was too busy, however, you'd be jumping from the frying pan into the
fire if you switched from say, Kim to Ernie, Sandy or Mike during the day. I say
this is technically possible, but Ernie, Sandy and Mike don't have the same
software installed as Kim and Charm (and visa-versa) so your jobs probably
wouldn't run on those systems anyway. We will be adding more Kim's, Charm's and
Ernie's to the cluster in the next few months so the SET HOST scheme may become
more of a possibility. We plan to make the first new VAX a processor dedicated
to batch jobs. You'd still be able to SET HOST to it, but you may not want to if
it has 4 to 6 batch jobs running on it all the time. More about this as things
develop. 

These features, however, do not come free. The cluster node that has the user
authorization, mail, network, job que and rightslist files has to remain up or
the whole cluster would grind to a halt (crash). I'm going to put those files on
the system with the highest reliability whichever one that might be. Accessing a
file through the cluster costs both CPU time and access time. The raw data rate
is roughly 1/2 of what it is via a locally connected disk and between 10 and 25%
of both systems invloved in the I/O dissappears during the transfer. We are not,
for most of the applications that we run on Kim and Charm anyway, anywhere near
being I/O bound so that might not even appear noticeable. 


From:	KIM::SHEPPERD     12-MAR-1987 15:53:33.92
To:	@dups,SHEPPERD    
CC:	
Subj:	One for all...

You guys currently have accounts on more than one system. Beginning on Monday
morning, EVERYONE will have an account on ALL the systems. This is available
because after that date there will be a single user authorization file. This
file will point your default login to a single node and no matter which system
you login on, you will always be pointing to that same "home" directory. 

The consequence of this is that you will no longer be able to get at your MAIL
messages on a particular node by just logging on on that node. What you will
have to do (or even what you can do now) is, once in MAIL, type:

	MAIL> SET FILE node$USERDISK:

where "node" is the node name on which you wish to read mail. If your mail
directories are not named the same on each different node, then you'll need to
specify the directory in addition to the node$USERDISK:. For example, in my
case, I've SET MAIL_DIR on all the nodes except ERNIE to [.MAIL] so I'd have
to type:

	MAIL> SET FILE ERNIE$USERDISK:[SHEPPERD]

to get to my mail messages on ERNIE.

This also implies that only the LOGIN.COM file that is present in your home
directory will be run at login. If you have procedures that need to be run
differently on each node (as many of us do), then you'll need to use
conditional execution in your LOGIN.COM file such as:

	$ node := 'f$getsyi("NODENAME")	!see which node we are, trim spaces
	$  kim   = "IF node .EQS. ""KIM"" then "
	$ _kim   = "IF node .NES. ""KIM"" then "
	$  charm = "IF node .EQS. ""CHARM"" then "
	$ _charm = "IF node .NES. ""CHARM"" then "
	$ kim  $ do_kim_only_command
	$ _kim $ do_command_only_if_not_kim
	$ _kim _charm $ do_command_if_not_kim_and_not_charm

You get the picture?

ds

Starting today, everybody has an account on every computer. This means that
MAIL "knows" about everyone on every node all the time. You no longer need
to specify a node name when mailing to someone, and you should remove all
references to node names in any .DIS files that you may have made. MAIL
will stil work if you use a node name, but you'll find to be MUCH faster
if you don't (and everyone else will benefit from the reduced CPU loads too).

ds

Ok, ok, ok...It's back to the way it was (sort of). If you login to a system
where you have a local LOGIN.COM in a directory on the local USERDISK named the
same as it is on your home system, then the system will execute that login,
define SYS$LOGIN to point to that directory and SET DEFAULT to the new
SYS$LOGIN. If not then it'll execute your LOGIN.COM on your home node and leave
your default there. For example: 

	User FRED's home directory is KIM$USERDISK:[FRED]
	He also owns the directory CHARM$USERDISK:[FRED] and it has
		a LOGIN.COM file in it.
	He also owns the directory ERNIE$USERDISK:[FRED] and it doesn't
		have a LOGIN.COM file in it.
	He has no directory on SANDY

	If FRED logs in on CHARM, it'll execute the LOGIN.COM file in
	CHARMUSER$DISK:[FRED] and set his default there too.
	If he logs into ERNIE or SANDY, then, since there's no LOGIN.COM file,
	it'll execute KIM$USERDISK:[FRED] and leave his default at KIM. 

ds