Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!decvax!decwrl!pyramid!hplabs!ucbvax!CITHEX.CALTECH.EDU!carl
From: carl@CITHEX.CALTECH.EDU.UUCP
Newsgroups: mod.computers.vax
Subject: Decnet Etiquette
Message-ID: <860717043514.009@CitHex.Caltech.Edu>
Date: Thu, 17-Jul-86 07:35:14 EDT
Article-I.D.: CitHex.860717043514.009
Posted: Thu Jul 17 07:35:14 1986
Date-Received: Thu, 17-Jul-86 23:41:13 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 27
Approved: info-vax@sri-kl.arpa

There's  been  a  lot of traffic through this teleconference recently involving
execution of commands on a remote host via DECnet.  There has also been, in the
past  year, a significant amount of munching on at least one large (>500 nodes)
DECnet, some of it involving exactly the sort of procedures being circulated in
response  to  questions  in this TC.  This prompts me to remind participants in
this  TC  of  what  might  be  termed a point of DECnet etiquette:  The default
DECnet  account  tends  to  be charged to some sort of overhead account on many
VAXen,  so  any  costs  associated with its use tend to be unrecoverable in any
useful  sense;  further,  because of the fact that it tends to be accessible to
anybody  on  the  same  DECnet,  system managers, or on systems with a separate
security  manager,  the security manager, tend to view use of that account that
doesn't  fit  their expectations for that use (e.g., new .COM files showing up,
execution  of  images  they hadn't intended be available to that account, sharp
increases in system resource consumption, etc., ad nauseum) with some degree of
alarm.   Their reactions to such use can vary from ignoring the usage to severe
restrictions  on  the  use  of  the account, even so far as cutting off default
DECnet  access  from  all  but  selected nodes, and such reactions are, in many
cases,  justified.    Therefore, it behooves you, in the event you want to have
the  account  do  something  it  didn't  do  in the past, to contact the system
manager of the appropriate machine and ask for his advice on 1) whether the use
is  appropriate  (if  not, your next step is to negotiate for an account on his
machine)  and  2)  what the appropriate means of implementing the new use might
be.    Failure  to  do  so  can lead to loss of DECnet access to the machine in
question for virtually all users on the DECnet, so it seems to me that the time
and  effort  to make such inquiries is quite justified.  Besides, if you find a
friendly  system manager, he can be a valuable source of information on how you
can make VMS work for you more efficiently.