S211KENO@HTIKHT5.BITNET.UUCP (01/16/87)
> 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. I think what you want can be achieved with identifiers (either granting them permant with the AUTHORIZE utility or dynamically with the new V4.4 SET RIGHTS command, which you can use in your SYLOGIN.COM). You have to create an empty file (i.e. SYS$MANAGER:NODES.ACCESS) with the desired ACL. This ACL should contain the identifiers of the cluster nodes and the one's you granted to the users. By combining them and having the ACE's in the right order you are as flexible as you want. And you also might want to use identifiers like INTERACTIVE, BATCH etc. In SYLOGIN.COM you $ open/read/share=read/error= SYS$MANAGER:NODES.ACCESS If the file can't be opened (due to a privilege violation) a nice error message can be generated saying this user is not allowed to login on this node, followed by the LOGOUT command. Example of such an ACL: NODES.ACCESS;5 [1,4] (RWE,RWE,RE,R) (IDENTIFIER=STUDENT+SYS$NODE_KUBPRA,ACCESS=READ) (IDENTIFIER=DOCENT+SYS$NODE_KUBPRA,ACCESS=READ) (IDENTIFIER=STUDENT+INTERACTIVE,ACCESS=NONE) (IDENTIFIER=INTERACTIVE+SYS$NODE_KUBPRA,ACCESS=NONE) This gives users with identifiers STUDENT or DOCENT access to node KUBPRA, it denies interactive access of STUDENT-users to other nodes, and it denies interactive access to node KUBPRA for users without identifiers. Big advantage: changes can be applied immediately with EDIT/ACL Of course you can also put this ACL on DCLTABLES.EXE, DCL.EXE or SYLOGIN.COM, but the resulting error message at LOGIN might be confusing. The identifiers SYS$NODE_...... are available from VMS V4.4 on. ----------------------- Kees S211KENO@HTIKHT5.BITNET