SYSJAMIE@utorphys.BITNET (James MacEwan) (06/15/88)
What you might want to do is put several branches in your
sys$manager:sylogin.com file. Look on page 5-7 of the SYSTEM MANAGER'S
REFERENCE MANUAL to see what it is all about sylogin is about.
You could call subroutine's based upon which department they are in,
(for ex, IF f$getjpi("","GRP") .eq. xx then GOSUB DEPTXX ...)
using simple DCL GOSUB. Or if you don't need to return from the subroutine
just use GOTO.
I would put all the branch routines in one file (if it doesn't become too big)
to ease your own system management. (If there are too big just do @'s)
Sorry if this is too obvious. (I do recall asking an obvious question myself
once.)
sysjamie@utorphys.bitnet
sysjamie@helios.physics.toronto.edu
J.CADS_COLE@GALLUA.BITNET ("Kevin Cole at Gallaudet U. Washington DC") (06/15/88)
Date sent: 15-JUN-1988 08:10:32 Michael Joe Walters <MWALTERS@UWYO.BITNET> writes: >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? Fairly easy I would think... Set up a directory where all the .COM files are protected in a way that allows the appropriate parties to read them. Then (and this is probably the simplest to implement), just set up LOGIN.COM's at the account level which execute the appropriate COM files in other areas. For example, create a directory called [COMMON-DIR]. Create some COM files like: DIVISION.COM, DEPARTMENT-1.COM, DEPARTMENT-2.COM, etc. and make sure the directory and the files have a protection which allows them to be read. Accounts 1-4 in department one Accounts 1-4 in department two have LOGIN.COM's start like: have LOGIN.COM's start like: $ @[COMMON-DIR]DIVISION $ @[COMMON-DIR]DIVISION $ @[COMMON-DIR]DEPARTMENT-1 $ @[COMMON-DIR]DEPARTMENT-2 (Ultimately, you could get much more complicated and just have one huge master COM file which has the smarts in it to decide which account called it and behave in whatever fashion you desire after that, but you said you weren't a technical person...) ------------------------------------------------------------------------------- Kevin Cole <Flatline> BITNET: KJCOLE@GALLUA.BITNET Center for Assessment and or Demographic Studies (CADS) CADS_COLE@GALLUA.BITNET Gallaudet Research Institute (GRI) UUCP: ...!psuvax!gallua.bitnet!kjcole Gallaudet University CompuServe: 76167,1406 Washington, D.C. 20002 (202) 651-5575 "Hey Rocky! Watch me pull a rabbit out of my hat!"
MCGUIRE@GRIN1.BITNET ("The Sysco Kid ", McGuire,Ed) (06/15/88)
--------------------------- Begin Forwarded Message -------------------------- Date: Wed, 15 Jun 88 9:43:04 cdt From: "The Sysco Kid (McGuire,Ed)" <MCGUIRE@GRIN1.Bitnet> To: mwalters@uwyo.bitnet cc: "McGuire,Ed" <MCGUIRE@GRIN1.Bitnet> Subject: Re: Structure/Login.Com question Michael, I'll suggest one solution and you can apply the technique in other creative ways as you think of them. Let us imagine that your VMS file directories are organized parallel to your corporate structure. I'll illustrate with an example. There is a directory for the entire accounting division called [ACCOUNTING], a subdirectory for the audit department called [ACCOUNTING.AUDIT], and a subdirectory for auditor Jane Doe called [ACCOUNTING.AUDIT.JANE]. When Jane logs in, her default directory is [ACCOUNTING.AUDIT.JANE]. Now the DCL command @[--]LOGIN will run the LOGIN.COM in [ACCOUNTING] and the command @[-]LOGIN will run the one in [ACCOUNTING.AUDIT]. Put those lines in your SYS$MANAGER:SYLOGIN.COM. (Jane's personal LOGIN.COM in [ACCOUNTING.AUDIT.JANE] is run after SYLOGIN by the login program.) The same commands will also set Mira Doe's account up correctly even though she is in [DEVELOPMENT.WIDGETS.MIRA]. That is, the [DEVELOPMENT]LOGIN will run, then the [DEVELOPMENT.WIDGETS]LOGIN will run, and then her personal LOGIN. Do you see what I mean? Ed ---------------------------- End Forwarded Message ---------------------------
SYSRUTH@utorphys.BITNET (06/16/88)
Use the LGICMD flag in the AUTHORIZE utility. This allows you to
specify a particular file as the initial login.com for each user.
You can do this in either of (at least) two ways:
1. Create a login.com-type file for each division and set the LGICMD
flag for each account in each division to the appropriate file.
Remember to @sys$login:login.com at the end so the user's own
login.com gets run as well. Optionally you could have finer
subdivisions within them, each with its own file; however it
might be better in this case to have each user execute this file
as the first line in his/her own login.com. That way you don't have
to have a program which will decide who is in which group.
2. If you have things you want everyone to define, keep using your
sylogin.com, and then use some scheme for determining who is in
which division (search a file or something?) and @ that division's
file. In this case it is not necessary to explicitly call the
user's own login.com. Leave the LGICMD flag as just plain LOGIN
and both the file you assign to sys$sylogin and sys$login:login.com
will be executed.
Hope this gives you some ideas.
Ruth Milner
Systems Manager
University of Toronto Physics
BITNET: sysruth@utorphys INTERNET: sysruth@aurora.physics.toronto.edu