mwalters@UWYO.BITNET (Michael Joe Walters) (06/15/88)
Sorry if you received two copies of this. I sent the first one to the wrong
address.
I have a question that I am hoping someone on the discussion list can
help me with. I work with a structure that I will draw a picture of
(a picture is worth a thousand words?).
Division
|
|
__________________________________|___________________________________
| | | | |
| | | | |
Dept. 1 Dept. 2 Dept. 3 Dept. 4 Dept. 5
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
Multiple Multiple Multiple Multiple Multiple
Accounts Accounts Accounts Accounts Accounts
What I am looking to do (and I am not a technical person) is this. We want
to have LOGIN.COM files or something similiar that reside in the directory of
the Division level and each of the department levels. Then when one of the users
login the LOGIN.COM will be executed on the division level first, the department
level next, and if it exists, the account level next.
With this kind of setup a division could placed information in the LOGIN.COM
that is only necessary for that division. This might include messages,
important information, etc. Everyone in that division would execute the
LOGIN.COM file when they login. The departments could also do the same thing
with each person in that department executing the division and then the
departmental LOGIN.COM.
My question is can this been done without any changes to VMS? Has anyone
implemented something similar?
Many thanks in advance as this is becomming a political issue and I hope to
head it off. Thanks again.
Michael Walters
MWalters@UWYO.BITNET"Bruce_G._Kahler.rochX2"@XEROX.COM (06/22/88)
While mulling over the question about executing separate login.com files for division, department, and individual, I was reminded by the AUTHORIZE manual of an option I'd forgotten (if I ever knew it): the LOGIN command file does not have to be in the user's default directory; it can be anywhere as long as the user has read-access (just put the full file spec in the /LGICMD qualifier in the UAF). This suggests the possibility of a generic top-level login.com that executes the appropriate division, department, and user login.com files by parsing the user's default directory tree, from the lexical function F$DIRECTORY, e.g. By doing it this way instead of , for example, having each user's login.com execute the appropriate division and department procedures, the upper-level ones are protected from users' deciding they want to bypass them, etc. Good Luck.
terrell@musky2.MUSKINGUM.EDU (Roger Terrell) (06/22/88)
In article <880614235635.204008b0@UWYO.BITNET> mwalters@UWYO.BITNET (Michael Joe Walters) writes: > Division > | > | > __________________________________|___________________________________ > | | | | | > | | | | | >Dept. 1 Dept. 2 Dept. 3 Dept. 4 Dept. 5 >| | | | | | | | | | | | | | | | | | | | >| | | | | | | | | | | | | | | | | | | | >| | | | | | | | | | | | | | | | | | | | > >Multiple Multiple Multiple Multiple Multiple >Accounts Accounts Accounts Accounts Accounts > >What I am looking to do (and I am not a technical person) is this. We want >to have LOGIN.COM files or something similiar that reside in the directory of >the Division level and each of the department levels. Then when one of the users >login the LOGIN.COM will be executed on the division level first, the department >level next, and if it exists, the account level next. This is fairly easy to do. I assume that you have a system-wide login.com (SYSLOGIN) already; on our site, that .com file determines whether or not the LOGIN.COM of an individual exists, and runs it if it does. It determines if the file exists by using the OPEN command, jumping to a certain label in the SYSLOGIN file if it receives an error (there is a qualifier to OPEN that lets you do this). If it does not receive an error then it executes the .com file. We also have another .com file that holds extra definitions that we want certain groups to have. We simply get the UIC or GROUP from the F$GETJPI lexical function and, if the person logging in is in the proper group, execute the command file that creates the extra definitions. I hope this helps. If this is not enough information, let me know and I will whip something up and e-mail it to you. --Roger -- Roger Terrell ...musky2!terrell (UUCP) terrell@muskingum.edu (CSNet)
cfchiesa@bsu-cs.UUCP (Christopher Chiesa) (06/23/88)
In article <880614235635.204008b0@UWYO.BITNET>, mwalters@UWYO.BITNET (Michael Joe Walters) writes: > > I work with a structure that I will draw a picture of > (a picture is worth a thousand words?). [so is disk space. picture deleted. - CFC] > [... we want] > to have LOGIN.COM files or something similiar that reside in the directory of > the Division level and each of the department levels. Then when one of the > users login the LOGIN.COM will be executed on the division level first, the > department level next, and if it exists, the account level next. Normally I would have said, "yes, it's easy: have each user maintain a LOGIN.COM which, at the beginning, contains statements along the lines of $ @ <division_level_directory>DIVISION_LOGIN $ @ <department_level_directory>DEPT_LOGIN ... but your last clause betrays this solution: "... and IF IT EXISTS, the account level next." That implies that you want to do all this WITHOUT the necessity for the user to have a LOGIN.COM in his own directory, that which I would have considered the simplest solution. Perhaps you want to avoid grant- ing each user control over which Division and/or Department LOGIN.COM he exe- cutes; fair enough. The only other alternative of which I'm aware is the system-level login, named I believe SYLOGIN.COM ; not sure what directory that's in because I'm not a sys- tems person myself. At that point, you'd have to invoke a utility program to match up usernames to departments and divisions. It ought not require any modification to VMS, just a bit of programming within the existing system.. (Hey, here's an idea -- hire ME! I'm a recent graduate, good in VMS, and am available... e-mail if interested! ;-) ) -- UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!cfchiesa cfchiesa@bsu-cs.UUCP
IJAH400@INDYVAX.BITNET (06/29/88)
< an option I'd forgotten (if I ever knew it): the LOGIN command file does not
< have to be in the user's default directory; it can be anywhere as long as the
< user has read-access (just put the full file spec in the /LGICMD qualifier in
< ...
< By doing it this way instead of , for example, having each user's login.com
< execute the appropriate division and department procedures, the upper-level
< ones are protected from users' deciding they want to bypass them, etc.
And I was reminded of something I forgot: read-access isn't necessary, you
can execute a command procedure with only execute access to the file...
- Jim Harvey
IJAH400@INDYVAX or IJAH400%IVAX.DECNET@GOLD.BACS.INDIANA.EDUjmb@beach.cis.ufl.edu (John M Boof) (07/02/88)
In article <3326@bsu-cs.UUCP> cfchiesa@bsu-cs.UUCP (Christopher Chiesa) writes: > ( ...a referred to article concerning having several levels of > login.com files executed when a student logs on... ) > ( ...a suggestion to use the system login command file to maintain > this...) What I believe to be the best solution is to alter the name of the login command file used by each of these accounts so that they run the highest level login.com. Then the highest level one (Departmental) runs the appropriate next level login ( Instructor's ), and that login checks if the individual has their own login.com file and runs it if so. This gives direct control to the highest level login, and allows lower levels to alter/add intervening levels and such. The default login command file used when a person logs on is determined in the UAF file and can be altered in AUTHORIZE with a 'MODIFY/LGICMD=filespec' command. 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. I wouldn't suggest cluttering the system's login command file with maintennance of which login files to run for which users, and in which order, etc... Also, it sounds like your numerous login procedures may delay the time delay to wait for your first DCL prompt to a frustrating level. ...JMBoof _____________________________________________________________________________ Addresses in order of preference: ARPA-InterNet: VAX/VMS: boof%oak.decnet@pine.circa.ufl.edu or boof@pine.circa.ufl.edu Gould UNIX: jmb@beach.cis.ufl.edu UUCP: Gould UNIX: ... !ihnp4!codas!uflorida!beach.cis.ufl.edu!jmb BITNET: VAX/VMS: boof@ufpine or boof@ifasgnv IBM VM/CMS: $$$YEQ#@NERVM _____________________________________________________________________________
ijah400%ivax.DECnet@GOLD.BACS.INDIANA.EDU ("IVAX::IJAH400") (07/07/88)
John M. Boof <mailrus!uflorida!beach.cis.ufl.edu!jmb@CSD1.MILW.WISC.EDU> 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
ijah400%ivax.DECnet@GOLD.BACS.INDIANA.EDU ("IVAX::IJAH400") (07/07/88)
Oops, acck, ptth! My reply to John Boof's reply concerning departmental login command procedures was in error: <John M. Boof <mailrus!uflorida!beach.cis.ufl.edu!jmb@CSD1.MILW.WISC.EDU> <writes (about having a hierarchy of login command procedures for users): < ... << 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. No, it also keeps you from SPAWNing subprocesses under certain circumstances. I had set my own account Captive to test this and forgot to turn it off. Then when I was reading my mail today, I tried to spawn out and got a nasty message from VMS MAIL telling me I was crazy for trying to do it from a captive account. Oh well: "Wrong thinking will be punished severely".... - James Harvey IJAH400@INDYVAX (BITNET) or IJAH400%IVAX.DECNET@GOLD.BACS.INDIANA.EDU
ijah400%ivax.DECnet@GOLD.BACS.INDIANA.EDU ("IVAX::IJAH400") (07/07/88)
Oops, acck, ptth! My reply to John Boof's reply concerning departmental login command procedures was in error: <John M. Boof <mailrus!uflorida!beach.cis.ufl.edu!jmb@CSD1.MILW.WISC.EDU> <writes (about having a hierarchy of login command procedures for users): < ... << 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. No, no, it also keeps you from SPAWNing subprocesses under circumstances, and disables CTRL/Y interrupts. I had set my own account Captive to test this and forgot to turn it off. Then when I was reading my mail today, I tried to spawn out and got a message from VMS MAIL telling me I was crazy for trying to do it from a captive account. Oh well: "Wrong thinking will be punished severely".... - James Harvey IJAH400@INDYVAX (BITNET) or IJAH400%IVAX.DECNET@GOLD.BACS.INDIANA.EDU