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. Boofwrites (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