From: CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 21-MAR-1989 21:04 To: MRGATE::"ARISIA::EVERHART" Subj: Thoughts On Sharing SYSUAF And Other System Files In Clusters... Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Tue, 21 MAR 89 17:31:59 PDT Received: from remote.dccs.upenn.edu by KL.SRI.COM with TCP; Tue, 21 Mar 89 17:08:31 PST Received: from XRT.UPENN.EDU by remote.dccs.upenn.edu id AA24923; Tue, 21 Mar 89 13:51:54 EST Message-Id: <8903211851.AA24923@remote.dccs.upenn.edu> Date: Tue, 21 Mar 89 13:53 EDT From: "Clayton, Paul D." Subject: Thoughts On Sharing SYSUAF And Other System Files In Clusters... To: INFO-VAX@KL.SRI.COM X-Vms-To: @INFOVAX,CLAYTON Greg Hamm, from Waksman Institute in NJ, USA asks about the sharing of SYSUAF in a hetrogeneous type cluster to aid in the management of the user quotas and assorted other goodies. For this I offer the following comments. 1. There is nothing stopping each system, or group of systems, from having a common UAF. The issue is that each CPU BOX must have only one, where it resides is up to the system manager. How many to have is also up to the system manager and dictates the size of the headache that will be brought on with each update. The trick is the logical name SYSUAF, done at SYSTEM level with EXEC mode access. You could have one UAF file for all the VS2000's that was in one directory, does not have to be any system directory either, and in the VS2K boot file make the logical name such as the following. $assign/system/exec disk:[dir]VS2UAF.DAT SYSUAF Along the same lines, you could have another UAF file for the 11/785 which would be different from the one above and the logical name would be used to point the system to it, for example. $assign/system/exec disk:[dir]785UAF.DAT SYSUAF This trick was done for those poor souls, like myself, who have had to live with multiple system disks, even in a homogeneous type cluster. Be VERY careful about file and directory protections if some directory other then a SYS$SYSTEM directory is used! 2. There are problems with this type setup. There will be multiple UAF's to maintain. If a user has any of the larger, more powerful privs, then he/she could override this logical and do something else with it. 3. The benifits are that 'groups' of CPU's could be handled in a like fashion. You could even go so far as to use the logical RIGHTSLIST to point to a common rights list database so that if your site uses ACL's at least you would not have to define the id's for each 'group' of CPU's. Watch out for id's with the same name, but different meanings for different CPU's here though. 4. If the users are in a captive menu you can test for the type of machine using the F$GETSYI lexical function and based on that, set the user quotas, and even privs. to be LESS then or EQUAL to the UAF values. This would get around having a low WSMAX for certain processors to try and limit the 'damage'. 5. If you are in a V5 NI/CI cluster setup and you are playing these games, then beware when using the SYSMAN utility for UAF type jobs. You only need to touch the UAF once per 'group' of processors using the same UAF file. Hope this helps some with the headaches. My own fix is to take two asprin, with a Coke/Pepsi chaser, before working the UAF files and the like. Have fun... pdc Paul D. Clayton Address - CLAYTON%XRT@RELAY.UPENN.EDU Disclaimer: All thoughts and statements here are my own and NOT those of my employer, and are also not based on, or contain, restricted information.