Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!GOLD.BACS.INDIANA.EDU!ijah400%ivax.DECnet
From: ijah400%ivax.DECnet@GOLD.BACS.INDIANA.EDU ("IVAX::IJAH400")
Newsgroups: comp.os.vms
Subject: Re: Login.com question
Message-ID: <8807080910.AA11713@ucbvax.Berkeley.EDU>
Date: 6 Jul 88 18:18:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 34

John M. Boof 
writes (about having a hierarchy of login command procedures for users):
< (...suggestion of using AUTHORIZE with MODIFY/LGICMD=filespec to run the
<  highest level login command procedure (Departmental) which then runs the
<  next highest (instructor) then the individual user's, etc.  This way
<  each level has direct control over the next)
<  ...
< But you must remember that the account can be logged onto bi-passing
< this default login command file with a 'Username: ME/COMM=...' or
< 'Username:  ME/NOCOMM' entry when logging on.

Not if you set the Captive flag (MODIFY/FLAG=CAPTIVE).  All the captive
flag does is keep users from giving qualifiers at login; whether the account
is really "captive" or not depends on what kind of login command procedure(s)
you give them.

< ...
< Also, it sounds like your numerous login procedures may delay the time
< delay to wait for your first DCL prompt to a frustrating level.

One way to reduce this time is a simple trick we use here (I've seen it
mentioned in various magazines also).  For example, at system startup,
we define "WPS" foreign command as WPS*PLUS :== @somewhere:WPSPLUS_INIT.COM.
WPSPLUS_INIT.COM simply contains:

$ @Digital-supplied-WPSPLUS-login-procedure
$ WPSPLUS

The Digital WPS login procedure redefines the symbol WPS*PLUS to do the
right thing (run WPSPLUS I suppose).  This way, only people who actually
use WPS have to sit around and wait for the initialization stuff for it.

	- James Harvey
	IJAH400@INDYVAX (BITNET) or IJAH400%IVAX.DECNET@GOLD.BACS.INDIANA.EDU