A User Friendly Interface to VMS disk quotas

Julian J. Bunn CERN, Geneva, Switzerland.

* * *

Paper presented at the 1987 DECUS Europe Symposium, Rome. 1st. July 1987

A software tool which simplifies access to disk quota information in VMS is described. The tool is written in FORTRAN 77 using VMS System Service calls, and is installed as a VMS command called "SPACE" using the Command Definition utility.

It is shown how the definition of the command allows easy access to the quota file for a given disk. Group administrators (holding a specific rights identifier) use the "SPACE" command to move disk quotas around within their own group. For this purpose each group is initially allocated a substantial pool of disk space. A typical example is the command


which has the effect of transferring 1000 blocks of disk space from the group pool to user HARRY.

Several additional features are described, together with the particular environment in which the SPACE command is used at CERN, the European Laboratory for Particle Physics.

The CERN Environment.

CERN is an international organisation situated just outside Geneva on the border between Switzerland and France. At CERN many large experiments are in progress which investigate the properties of subatomic particles, in an effort to provide a better understanding of the forces of nature. At present, construction of a very large e@+e@- particle collider is in progress; this is called LEP. Four separate experiments will investigate the physics of the collisions when LEP begins operation in a couple of years. These LEP experiments number typically three hundred physicists, engineers, programmers, technicians and secretaries, and are already involved in writing and testing software which will perform the necessary analysis of electronic data taken at LEP.

Extensive computing facilities are provided at CERN for such analysis, together with the monitoring and control of the particle colliders themselves. The main facilities serve not only the CERN site, but also external physicists and engineers who gain access to them over a variety of networks. The CERN computer centre includes IBM, Siemens and DEC computers, which are used by over five thousand registered users. A Cray X&hyphen.MP/48 vector supercomputer is due to be installed this October.

The Computing Division at CERN includes a User Support group, the members of which deal with the administration of the facilities, user problems (of a computing nature), software utilities, and so on. Members of the User Support group act as resource managers/administrators on the available systems, although the operation of the hardware itself is not their concern.

In April 1985, a DEC VAX 8600 was made available for use by the four LEP experiments plus a small number of selected users from various other experiments. Each LEP group appointed an administrator from the group who was responsible for registering new users, allocating disk space, and so forth. The VAX service was recently expanded to include a VAX 8800, with the 8600 being upgraded to an 8650. Following this, non&hyphen.LEP experimental groups were invited to use the central VAX service. These groups were typically involved in smaller experiments where the data&hyphen.acquisition computer was a VAX. For them, the opportunity to test and de&hyphen.bug software on a powerful central VAX was very attractive.

User groups

The new (non&hyphen.LEP) groups were asked to nominate a person who would act as the group administrator, the duties of whom would be to control the use of the available resources. The group administrator would preferably have some experience of working on the VAX, and would act as far as possible as a first&hyphen.level of user support to those people in the group.

Applications for registration of a group had to be accompanied by a fairly detailed description of what use the group expected to make of the VAX (estimated CPU time, tape mounts etc.), and had to be authorized by the signature of the spokesperson or group&hyphen.leader. On receipt of the group registration request, the User Support group in the Computing Division then allocated an unused octal number for the group part of the VMS UIC, and assigned the group a two&hyphen.letter "group code". This two&hyphen.letter code would agree with the code already existing for the group on the other computer systems at CERN, if that group already had accounts on those systems.

Once the group UIC number and two&hyphen.letter group code had been assigned, the physical disk on which the filebase of the group would sit was chosen. A logical name DISK$GG was added to the system logical name table, pointing to this physical disk (where GG was the two&hyphen.letter group code). (Groups with members having files on more than one disk are not allowed, except in the case of the LEP groups.) In addition, a rights identifier holding the attribute of resource was created called PUBGG (short for "PUBlic space for group GG"), having the value

PUBGG  =  [group_uic,*]

where group_uic was the group UIC number. In this way, anybody subsequently registered in group GG would obtain by default the PUBGG identifier.

An extract from the command file used to create the group is shown below: ADDGROUP.COM

$ write sys$output -
"----------------- add the identifier to the database -------------"
$ mc authorize add/id/val=uic:['uic',*]/att=(res,nodyn) pub'gg'
$ write sys$output -
"----------------- create DISK$SCRATCH directories ----------------"
$ cre/dir/prot=(g:rwe,w)/owner=pub'gg'/log disk$scratch:[pub'gg']
$ cre/dir/prot=(g:rwe,w)/owner=pub'gg'/log disk$scratch:[pub'gg'.week]
$ cre/dir/prot=(g:rwe,w)/owner=pub'gg'/log disk$scratch:[pub'gg'.work]
$ dir/size=all/date/security disk$scratch:[pub'gg'...]
$ write sys$output -
"----------------- create ''gg'_SYSLOG file -----------------------"
$ copy/log cern$manager:dummy_syslog.com cern$manager:'gg'_syslog.com
$ create/directory/log/own=pub'gg' 'dev'[pub'gg']
$ set file 'dev'[0,0]pub'gg'.dir/acl=(id=pub'gg'+id$_grpadm,-
$ set file 'dev'[0,0]pub'gg'.dir-
$ set file 'dev'[0,0]pub'gg'.dir/prot=(w:re,g:rwe,o:rwe)

Shown in this extract is the creation of the Access Control Lists (ACLs) that would be used to allow the members of the group access to the pool of space owned by PUBGG. This pool of space would be initially set to a value considered appropriate for the type of work the group had said it wanted to do on the VAX. Groups using the VAX for development of large physics analysis programs, and with a large number of members, would be allocated considerably more public space than those groups wishing to use the VAX just for accessing VMS Mail or Notes. A group might thus receive 2000 blocks of disk quota per user, plus 1000 blocks multiplied by the number of users in the group. In such a case, for a group of five users, the group quota would be 15000 blocks. In the event that the group ran out of public space, due to a larger number of users than anticipated, or an incompressible expansion of the filebase, then the group administrator would be required to apply for and justify an increase in the size of the group's public space to the User Support group. These requests were almost always agreed to.

The User Registration Procedure

Once the group name had been registered on the VAX, the group administrator himself was given an account. The only difference between this account and the subsequently registered accounts in the group was the granting of the identifier signifying group administrator status, namely


Once registered, and granted this identifier, the group administrator could go ahead and submit registration requests for new group members. Indeed, on request to User Support he could request that a user registered in his group also be granted the group administrator identifier; there was no limit imposed on the number of administrators in the group. To allow members of User Support to inspect and modify disk quotas for any user, the identifier ID$_BDGADM was granted to them. The holder of this identifier could over&hyphen.ride the validation of the group code in SPACE. The ACL shown in the extract from ADDGROUP.COM gives holders of ID$_GRPADM the control over the ACL; thus only the group administrators may change the access to the public space, even though all users in the group may create and delete files there.

Registration on the VAX at CERN is not a simple matter of adding a record into SYSUAF.DAT. The registration request must first be validated on the central IBM system, where a large database containing names and details of all known users on all known systems at CERN is kept. This validation ensures that the request forwarded to the VAX is 'clean' (for instance that the specified group UIC code is correct) and centralises all computer user information at CERN. Once validated, the registration is performed by a pseudo&hyphen.automatic procedure involving the creation of the record in SYSUAF.DAT, the creation of the user's top&hyphen.level directory on the group's disk (DISK$GG), the giving of the requested number of disk blocks to the identifier, the definition of the Login Command file to be that common to the rest of the group, and so on. A typical entry in SYSUAF.DAT after registration is shown overleaf. SYSUAF entry for BRED

Username: BRED                       Owner:  BINDOLO,F./EP
Account:  BNDVM                      UIC:    [1150,7] ([PUBVM,BRED])
CLI:      DCL                        Tables:
Default:  DISK$VM:[BRED]
Login Flags:
Primary days:   Mon Tue Wed Thu Fri Sat Sun
Secondary days:
No access restrictions
Expiration:            (none)    Pwdminimum:  5   Login Fails:     0
Pwdlifetime:           (none)    Pwdchange:   7-JUL-1987 12:19
Last Login: 10-JUL-1987 15:10 (int), 29-JUN-1987 15:21 (non-int)
Maxjobs:         0  Fillm:        20  Bytlm:        20000
Maxacctjobs:     0  Shrfillm:      0  Pbytlm:           0
Maxdetach:       0  BIOlm:        18  JTquota:       1024
Prclm:           2  DIOlm:        18  WSdef:          500
Prio:            5  ASTlm:        24  WSquo:          700
Queprio:         0  TQElm:        10  WSextent:      1800
CPU:        (none)  Enqlm:        30  Pgflquo:      25000
Authorized Privileges:
Default Privileges:
Identifier                       Value           Attributes
  ID$_GRPADM                     %X8001002C      NORESOURCE NODYNAMIC

There are several important points to note about this record:

  • The user is a group administrator (holding ID$_GRPADM).
  • The user has the identifier PUBVM, and can thus access the group's public space.
  • The account field (BNDVM) consists of a unique three letter user code followed by the two letter group code. This account field is the same for this user on all computers at CERN.
  • The user has a reference to the group&hyphen.specific login command file in CERN$MANAGER.
  • The user's default directory is on the group disk DISK$VM.
  • The rest of the record is not necessarily as it actually exists on the VAX at CERN.

Specification of the SPACE command

It was realised that the group administrators would require a tool to modify the disk space allocations of group members. It was felt that each group administrator should not be given the VMS privilege allowing him or her to modify the QUOTA.SYS file via the native VMS DISKQUOTA facility. There were several reasons for this decision:

  • A given physical disk might be shared by ten or twenty different groups, and such access would allow a group administrator in group ZZ to remove all the quota from a user in group YY !
  • The group administrator would usually want to move a number of disk blocks from one user to another in his group, rather than modify the PERMQUOTA for each user. (This method would not guarantee to preserve the figure for the total group space anyway.)
  • It was clearly desirable to have a fast and easily understood method of viewing the overall disk space situation in the group, i.e. only those users belonging to the group of the administrator making the query.
  • The difference between the number of disk blocks actually being used, and the allocated disk block quota, in other words the free blocks remaining, needed to be calculated and shown for each user in the group.
  • For User Support too, it was necessary to have a tool by which the space usage of all the groups on each physical disk could be monitored, particularly since the aim was to prevent over&hyphen.allocation of the available disk space. (An attempt is made to limit the sum of all space allocation on a given physical disk to the size of that disk.)

For these reasons the use of DISKQUOTA was ruled out, and the program SPACE was written.

The SPACE command in use

SPACE is installed with SYSPRV privilege so that the QUOTA.SYS file for any disk may be accessed, but in a controlled way, by any user holding the ID$_GRPADM or ID$_BDGADM rights identifiers. SPACE is an executable image accessed via a Command Language Definition (CLD) in a clear and simple way. There are basically three modes of operation for the SPACE command:

    Inquiry This mode shows the current disk block situation for a single user, a group of users, or all users on a disk. Modification This mode allows the transfer of space between two users on a disk. Administrators This mode shows a list of disk&hyphen.space administrators in the group.

Inquiry mode

For the group administrator of group Z1 the command SPACE * will produce the following list: .sk 7 SPACE output for group Z1

Group name  :Z1
01-JUL-1987 11:50:20.00
Disk name   :DISK$Z1
Look at everyone
   Name           Uses    Out of   Difference
------------   -------   -------   ----------
GRUMPY            2590      3000          410
HAPPY            10010     11000          990
PUBZ1                0      3000         3000
SNOWHITE             2      5000         4998
DOZY               508      1000          492
 Group Total     13110     23000         9890
SPACE finished without errors.

The command SPACE GRUMPY would thus produce: SPACE output for user GRUMPY

Group name  :Z1
01-JUL-1987 12:00:00.01
Disk name   :DISK$Z1
Look at user:GRUMPY
   Name           Uses    Out of   Difference
------------   -------   -------   ----------
GRUMPY            2590      3000          410
SPACE finished without errors.

For User Support, the SPACE command allows the inspection of any group or user registered on the system. Thus the command


will give a list of ALL users on the disk pointed to by the logical name DISK$Z1, and not only in group Z1. To restrict the list to users in group Z1, the command


would be used. The wildcard for the two letter group code in the first example is thus useful for making an audit of the space situation on a given mounted disk on the node; the result contains a global sum of the blocks in use, the allocated blocks and the free blocks. Before the introduction of the SPACE command at CERN, a common phenomenon was the over&hyphen.allocation by as much as 50% of some disks. By the use of a command called QUOCHK the disk space quota could be globally adjusted over all users to bring this figure to less than 100%. This having been done, the balance of the free space on the disk was given to an identifier QUOTA, which would from then on always keep the balance. To achieve this, requests for more public space by groups on a disk would be satisfied by a ..fo off SPACE /GIVE=xxxxx /FROM=QUOTA /TO=PUBGG /DISK=DISK$GG ..fo on type command, ensuring that the disk never became over&hyphen.allocated again.

Modification mode

If a group administrator is asked by one of the users in his group for more space then, typically, he will use the SPACE command in inquiry mode to decide from where that space will come. For example, if user GRUMPY has asked for an extra 1000 blocks, then the administrator can see that either the space must come from PUBZ1 or SNOWHITE. If he chooses to give GRUMPY the space from PUBZ1 then he will use the command: Giving GRUMPY space

 Group name  :Z1
 01-JUL-1987 12:20:15.50
 From user   :PUBZ1
 Give        :  1000 blocks
 To user     :GRUMPY
 Position after requested change:
 PUBZ1                0      2000         2000
 GRUMPY            2590      4000         1410
 SPACE finished without errors.

Notice that by default the space is taken from the public area. If the group administrator chooses SNOWHITE as the donor, then he will use the command:


Compare the one line command used for SPACE, with the commands needed to generate the same effect (but with no checking) using DISKQUOTA: Using DISKQUOTA for modifying quota


In each case, the SPACE command checks that either PUBZ1 or SNOWHITE has enough space to give to GRUMPY. In the event that this is not so: An illegal operation

 Group name  :Z1
 01-JUL-1987 12:20:20.50
 From user   :SNOWHITE
 Give        :  7000 blocks
 To user     :GRUMPY
 User SNOWHITE has only   4998 blocks to give
 SPACE will be aborted !!!

Alternatively, if the administrator decides that GRUMPY has too much space he might issue the command:


(which will probably make GRUMPY even more so). Again, by default the missing account is the public account, so that PUBZ1 ends up with another 400 blocks.


This mode of operation does not require that the user issuing the command is a group administrator; it is mainly intended for users who find they have run out of disk space and want to know who they should ask to give them more. The command SPACE /ADMIN issued by a user in group V7 would produce the following list: SPACE administrators for group V7

 User BROTON       is a group administrator for V7 Group UIC 2110
 User LORAT        is a group administrator for V7 Group UIC 2110
 User HOLYSMOK     is a group administrator for V7 Group UIC 2110
 ADMIN finished without errors.

Again, its use by members of User Support (holding the ID$_BDGADM identifier) allows the production of a list of ALL the group administrators on the system, thus:


where the wild card acts on the two letter group code.

How the SPACE command works


A short extract from the SPACE program is shown in Extract 9. For a copy of the complete program, please contact the author. SPACE.FOR

        INTEGER*4 FIB$L1
        INTEGER*4 FIB$L2
        INTEGER*4 FIB$L3
      ERR = 0
      LDISK = INDEX(DISK,' ')-1
         ERR = 1
         GOTO 999
      QF(1) = 0
      QF(2) = UIC
      QF(3) = 0
      QF(4) = NEW
      FILE_INFO.FIB$L_ACCTL     = 0
      FILE_INFO.FIB$L1          = 0
      FILE_INFO.FIB$L2          = 0
      FILE_INFO.FIB$L3          = 0
      FILE_INFO.FIB$L_WCC       = 0
      FILE_INFO.FIB$W_NMCTL     = 0
      DESC(1) = 28
      DESC(2) = %LOC(FILE_INFO)
      DF(1)   = 32
      DF(2)   = %LOC(QF)
     +                  ,DESC,DF,LFIELD,DF,,)
         ERR = 1
         GOTO 999
         ERR = 1
         WRITE(*,'(A)') ' No disk quota found on this disk'
         GOTO 999
      IF(QF(4).NE.NEW) ERR=2

The Command Language Definition

The CLD for the SPACE command is added into the System DCL tables using the SET COMMAND procedure. The definition is as shown in Extract 10. The CLD file for SPACE.

        PARAMETER P1,PROMPT="Users Name ",VALUE
        PARAMETER P2,PROMPT="Group Name ",VALUE
        PARAMETER P1,PROMPT="Group Name",VALUE


A command to inspect and modify disk space allocations has been written using VMS System Services in FORTRAN 77.

  • The command is installed with SYSPRV privilege in the system.
  • Usage of the command is restricted to users holding one of the necessary rights identifiers (ID$_GRPADM or ID$_BDGADM).
  • With the ADMIN qualifier, the command may be used by anyone on the system (and in this case just lists group administrators).
  • The group is defined as being a two&hyphen.letter substring of the SYSUAF Account field.
  • Modifications to the disk quota are only allowed for target users in the same group as the user performing the SPACE command (unless the user holds ID$_BDGADM).
  • Checks are made that re&hyphen.distribution of disk blocks by SPACE are within limits.


I would like to thank my colleague Federico Carminati for the original idea for the SPACE command, and for invaluable help in implementing it. I also wish to thank Harry Renshall for help with the specification of the command, suggestions for improvements to it, and for reading the draft of this paper.