The Group Quota Manager (GQM) The Group Quota Manager (GQM) program was written because I saw a crying need to get SOME sort of correlation between usernames and disk quotas. It was written under VMS V2.2, so there are some things it lacks (such as prompting help). On the other hand, some V3.0 enhancements were added, so GQM understands volume sets. In order for GQM to work, diskquotas must be enabled on the target device. Once that has been done, a series of initialisation commands must be issued to GQM, and then the diskquotas may be maintained by GQM indefinitely, and with much less agony than with DISKQUOTA. GQM also helps track down UIC's which own space, but aren't associated with a username. See the last section of this file for more information. GQM should be INSTALLed with SYSPRV, so that it may access its database file (in the MFD, and described later). It does not yet look for commands from the command line. (Next release...) The file GQMHELP.HLB should be moved to SYS$HELP, and where GQM.EXE goes is entirely up to you - there are no dependencies beyond the location of the help file. A minor note, to start off with: GQM may seem kludgy in some ways, and you can get some bizarre errors under certain circumstances, but IT WILL NOT MUNG ANY DISKS. It doesn't have prompting help (as noted above), and doesn't understand wildcards, and implements only write-access security. These will be forthcoming in the next release (hopefully ready for the Fall VAX SIG tape). So hold on, folks. Okey. Once quotas have been enabled with DISKQUOTA, here are the commands you must issue to get GQM primed for operation (It is assumed that DRA1: is the name of the target disk, and that GQM resides in SYS$SYSTEM): $ RUN SYS$SYSTEM:GQM GQM> USE DRA1: (At this point, you may or may not receive a message about a created file. The file involved is [000000]AQUOTA.SYS, which is used to keep track of account allocations.) GQM> REBUILD GQM> MAXIMIZE ACCOUNTS Page 2 (Here is where one of those bizarre errors may raise its head. You may get a message about an internal RMS bug, which I have been unable to track down. If you do, it means that the MAXIMISE operation is incomplete, and that you'll have to finish it by hand. Oh well.) GQM performs two levels of correlation: UIC to USERNAME, and USERNAME to ACCOUNT. The account is derived from the field of that name in the UAF. If you use that field for some other purpose, you may not be able to use GQM to its full extent. But at least you will have the first level of correlation available, and can ignore the second. Here's what GQM does: Each account (as described above) is granted a certain allocation by the system manager, or the equivalent. Privileged users (discussed momentarily) may apportion this among any and all of the users IN that account, but the total may never exceed this allocation. So, a research group may be granted 10000 blocks, and the wrangling over how it will be split up is taken out of the system manager's hands (and hair). The privilege which allows a user to muck around with the apportionment of space WITHIN HIS OWN ACCOUNT is SHMEM. Until such time as DEC (R) implements site-specific privilege bits, we'll have to stick with a little-used existing bit. There are three levels of security access implemented by GQM, which determine how much a user can mung allocations. The highest access, which I have labeled SYSTEM, is granted to all users who: have SYSPRV, OR have BYPASS, OR have a UIC group LEQ the SYSGEN parameter MAXSYSGROUP. A user who falls into this category can mung the quotas to his heart's content, with GQM'S blessing. This means you can remove and add users to the disk, and modify ACCOUNT allocations. The next level is called ACCOUNT level access, and allows the user to reapportion quota space WITHIN HIS OWN ACCOUNT ONLY. Users with SHMEM fall into this category. SYSTEM access implies ACCOUNT access. Commonly, this is available only to the [mmm,000] user for a particular account. The least-privileged access is called USER level, and allows the user to look at the quota allocations, but not make any changes. The previous access levels imply USER access, obviously. This is where a hole comes in: anyone can look at anyone else's quota and usage. Fixed in the next release... Page 3 The REBUILD function of GQM is very important. It is this function which does the actual calculating of how much is actually allocated to what accounts. All other commands assume this value is correct, and merely modify it. REBUILD must be issued any time a user is switched from one account to another, and when a disk is made available for GQM processing, but should not be necessary any other time. But it's not a bad idea to do one every month or so, to catch any oversights. The last major function of GQM deals with the vagrants - the name by which I refer to UIC's which own space (or have a quota), but are not associated with a username. These often occur when a username is deleted without having the files deleted as well, or when reading UNIX (R) 'tar' tapes, and occasionally with BACKUP. The command LIST VAGRANTS will show a list of all of these ownerless UIC's, and how much space is used by each. The REMOVE VAGRANT command will allow you to discard these when you have released or re-owned all file storage associated with them. Vagrants are treated as errors, and listed by the REBUILD command. Well, that's an overview of GQM. Read the help, and experiment. You cannot harm your disks with it. Good luck! Ken A L Coar