Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: new cluster suggestions... Message-ID: <8701161048.AA09242@ucbvax.Berkeley.EDU> Date: Fri, 16-Jan-87 05:48:27 EST Article-I.D.: ucbvax.8701161048.AA09242 Posted: Fri Jan 16 05:48:27 1987 Date-Received: Fri, 16-Jan-87 23:46:19 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 41 Approved: info-vax@sri-kl.arpa It seems likely that our site will be acquiring a second vax in the next few months.... I would like to use VMS in some way to "softly" segregate these user populations. So that segregation can be turned on and off as necessary. 45 weeks of the year the cluster would be available to all in an integrated manner, but when the crunch or complaints comes, all future logins get segregated.... The easiest thing to do is to define a system-wide login file, pointed to via SYS$SYLOGIN, that when activate - perhaps by the setting of some system-wide logical like SYS_SEGREGATE - checks to see if the account it is running in is allowed access to the machine it is on. If not, it complains and logs out. From DCL, you can easily access an indexed file, indexed by username, that indicates which machines each user may can access. You'll have to be careful about batch and perhaps network jobs. If you have a queue that feeds both systems, users will have no control over which one their job gets started up on. During the "peak" periods, you could set the common queue to feed only the student system; or you could have the system- wide login file define a logical name for that queue that feeds to the appropriate place, depending on the username; or you might decide that batch jobs should be allowed on either system. Network jobs would only be a problem if you set up a cluster alias and then had remote jobs coming in to user accounts via the cluster alias. Again, there are many ways to deal with this issue. Finally, let me note that the use of the SYS$SYLOGIN logical is essential. Users can over-ride the login command file specified in their UAF record with the /COMMAND or even /DISK qualifiers at login. They cannot, however, over-ride the SYS$SYLOGIN logical. (Of course, the first thing the file should do is disable CONTROL/Y.) Since EVERYONE will ALWAYS have to go through the command file SYS$SYLOGIN points to, keep it short, simple, and fast - if necessary, put any extensive (but not absolutely essential) stuff in a system-wide file pointed to by user SYSUAF entries. In particular, do NOT have the SYS$SYLOGIN file execute the user's login file. -- Jerry -------