.ap
.lm 10
.rm 70
.flags capitalize
.figure 4
.centre;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):
.skip 2
.lm +10
.literal
$ RUN SYS$SYSTEM:GQM
GQM> USE DRA1:
.end literal
.skip 1
.lm -10
(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.)
.lm +10
.skip 1
.literal
GQM> REBUILD
GQM> MAXIMIZE ACCOUNTS
.end literal
.skip 1
.lm -10
(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...
 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!
.skip 3
.i 30;Ken A L Coar