There's a new batch que on Kim and Charm that you are free to use which will
alternately submit jobs on each system in order to balance the batch job load. I
highly recommend that you use this, or at least try it a few times to see if it
really works. After a breakin period, I will make the procedure the default. In
your LOGIN.COM (at least those on Kim and Charm), place: 

	$ assign 780_BATCH SYS$BATCH

or, if you'd rather not "break" SYS$BATCH, then do submits as:

	$ SUBMIT/QUE=780_BATCH bla_bla...

or, 

	$ SUB*MIT :== SUBMIT/QUE=780_BATCH/NOTIFY...etc.

If you are one of those people with directories on both Kim and Charm, then
read on...

There could be a problem if you submit a job on Kim, it starts up on Charm
executes your LOGIN.COM file on Charm and that LOGIN.COM doesn't setup the same
environment as you've setup on Kim. Your batch job may fail because some symbol
or logical name hasn't been defined as expected or some such thing. When
we first went to common system authorization file, I chose to force everyone
to use a LOGIN.COM file in a "home" directory in order to remove these kinds
of problems, but that caused other problems instead. Soooo, I put it back the
way it was. Now with the BATCH system, it becomes yet again slightly different.
(I think this is how operating systems get so confused; the designers have to
use bandaids to make the system compatable and really make a mess of
things). 

What happens in BATCH is the system finds which disk the file you have submitted
lives on. It then "pretends" to have logged in on that system for the purposes
of looking for your LOGIN.COM and setting SYS$LOGIN. This will not work under
all circumstances, such as submitting a .COM file that lives on a different
node. Also the node conditionals that you may have in your LOGIN.COM file
will NOT be fooled by this. Anyway, try it. I will probably work fine for your
simple day to day stuff such as compiles, links etc.