🚀 go-pugleaf

    Our system-wide login.com procedure does a variety of site-dependant things
    for users.  We bypass it entirely for network logins (if f$mode() .eqs.
    "NETWORK" then $exit).  This is nice and quick for remote file access, and
    it avoids problems with user login.com files doing things like $INQUIRE;
    however it means that system-wide symbols and user generated symbols and
    logicals are not available.  What do other people do?  Any comments?

First, let's partition the problem.  You as system manager control the system-
wide command file.  You can - and should! - set it up so that it works cor-
rectly in any mode of operation.  There's no reason why you cannot provide the
appropriate definitions even for network jobs. The problem is with user
LOGIN.COM files.  Users will often include stuff in their own LOGIN.COM files
that break network processes.  Every system manager has had users come running
with complaints that "the network is broken" (or even "batch jobs don't work",
something that's just as likely - include a SET TERM/INQUIRE in a batch job
and it's all over) as a result of "unfortunate" LOGIN.COM files.  I've seen
systems where user LOGIN.COM files are just not executed for NETWORK jobs.
This (a) doesn't solve the problem of BATCH jobs; (b) is a real annoyance to
those of use who WANT our LOGIN.COM files to be executed, and have gone to
the trouble of making sure they work correctly.

My own LOGIN.COM file contains a number of tests.  For NETWORK jobs, for
example, about the only thing I care about is definitions of logicals, so
I skip over DCL symbol definitions - PLENTY of them! - and a variety of
other stuff.  (Much of this stuff would WORK in a NETWORK job, but would
do nothing useful - so why waste the time?)  Another decision is based on
whether SYS$COMMAND points to a terminal (basically, interactive vs. batch
jobs) and controls whether things like DEFINE/KEY's get done.  After all
this effort, as you can imagine I get annoyed when the system manager "pro-
tects" me and doesn't execute my file.

Ultimately, you're going to have to make a judgement based on your user
community.  If you have a group of hackers, a word to the wise should be
sufficient.  If you have a group of non-computer types, it probably doesn't
matter either way, since they are unlikely to change their LOGIN.COM file
anyway.  In the intermediate region, where a little knowledge is a dangerous
thing, my inclination would be to start people off with a LOGIN.COM file
already divided up into BATCH, INTERACTIVE, NETWORK, and common sections, with
appropriate comments like "put stuff having to do with the terminal here".
The best way to teach is by good example!
							-- Jerry
-------