JOHNC%CAD2.DECnet@GE-CRD.ARPA.UUCP (03/25/87)
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?
John Child
"Will there be anything else, sir?" General Electric
Aircraft Engines
Lynn, MAart@MITRE.ARPA.UUCP (03/26/87)
At the two sites that I have managed I used the following assumptions for
what was in the system-wide login.com
1) If it is a network login, bypass the entire login.com; but do execute
the users login.com (so he can bypass it if he wants). This was done for
speed. Most of the network accesses do not need the logicals and symbols.
They could define what they needed.
2) for Batch jobs I skipped over the definiton of symbols and logicals that
would only be used in interactive modes. These included INQUIRES, setting
terminal, and some processes that only run interactively.
The sample login.com provided to each user likewise had the tests for the
various classes of user so that they could learn to group the symbols by where
they would be executed.
I feel that it is often best to define a symbol that will load the symbols
needed by a program, rather than force everyone to incurr the overhead of
loading all of the sysmbols needed for each software package on the system.
One of the systems I have to occasionally use, takes over 10 cpu seconds
(some times this is 1-2 minutes wall clock) to execute the system-wide login.com
All of this just so I can check and see if I have any mail. I
definitely do not need to have all of the symbols loaded so that I can
run Eunice, Oracle, Ada, Issco, DI300, SAS, VIS1ON, MASS-11 and a
bunch of locally developed packages. If a few symbols had been
defined to point to the initialization files, the user could at login
or later select what symbols he wanted to load.
*
*---Art
*
*Arthur T. McClinton Jr. ARPA: ART@MITRE.ARPA
*Mitre Corporation MS-Z305 Phone: 703-883-6356
*1820 Dolley Madison Blvd Internal Mitre: ART@MWVMS or M10319@MWVM
*McLean, Va. 22102 DECUS DCS: MCCLINTON
*
=-=- This note is in response to yours which follows -=-=
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?
John Childdstevens@sitvxb.UUCP (03/27/87)
We use a similar procedure for our SYSLOGIN.COM file, but when a user does some network file access (provided proxies are working) then their own LOGIN.COM is also run. We also were told from Colorado Customer Support that the first line in SYSLOGIN.COM must be "if f$mode() .eqs. "NETWORD" - then EXIT". Otherwise the EVL process could start running haywire. David L. Stevens Stevens Institute of Technology BITnet: DSTEVENS@SITVXA.BITNET ARPAnet: DSTEVENS%SITVXA.BITNET@WISCVM.WISC.EDU CCnet: SITVXB::DSTEVENS Ps: Anyone have any comments on the validity of the EVL response from CCS ? Disclaimer: Its not my fault.
LEICHTER-JERRY@YALE.ARPA.UUCP (03/27/87)
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
-------