Julian J. Bunn
* * *
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
SPACE /GIVE=1000 /TO=HARRY
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.
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.
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
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:
$ 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,- option=protected+nopropagate,access=read+write+execute+delete+control) $! $ set file 'dev'[0,0]pub'gg'.dir- /acl=(id=pub'gg',option=default,access=read+write+delete+execute) $! $ 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.
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
$ MC AUTHORIZE GRANT/ID ID$_GRPADM FRED EXIT
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.
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.
Username: BRED Owner: BINDOLO,F./EP Account: BNDVM UIC: [1150,7] ([PUBVM,BRED]) CLI: DCL Tables: Default: DISK$VM:[BRED] LGICMD: CERN$MANAGER:VM_SYSLOG 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: TMPMBX NETMBX Default Privileges: TMPMBX NETMBX Identifier Value Attributes ID$_GRPADM %X8001002C NORESOURCE NODYNAMIC
There are several important points to note about this record:
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:
For these reasons the use of DISKQUOTA was ruled out, and the program SPACE was written.
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.
For the group administrator of group Z1 the command SPACE * will produce the following
list: .sk 7
$ SPACE * 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 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
SPACE /DISK=DISK$Z1 * *
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
SPACE /DISK=DISK$Z1 * Z1
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.
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:
$ SPACE /GIVE=1000 /TO=GRUMPY 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:
SPACE /GIVE=1000 /TO=GRUMPY /FROM=SNOWHITE
Compare the one line command used for SPACE, with the commands needed to generate the
same effect (but with no checking) using DISKQUOTA:
$ MC DISKQUOTA USE DISK$Z1 MODIFY /PERMQUOTA=4000 SNOWHITE MODIFY /PERMQUOTA=4000 GRUMPY EXIT
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:
$ SPACE /GIVE=7000 /TO=GRUMPY /FROM=SNOWHITE 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:
SPACE /TAKE=400 /FROM=GRUMPY
(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 /ADMIN 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:
SPACE /ADMIN *
where the wild card acts on the two letter group code.
A short extract from the SPACE program is shown in Extract 9. For a copy of the
complete program, please contact the author.
SUBROUTINE MOD_QUOTA(UIC,DISK,NEW,ERR)
STRUCTURE /FILEINFO/
INTEGER*4 FIB$L_ACCTL
INTEGER*4 FIB$L1
INTEGER*4 FIB$L2
INTEGER*4 FIB$L3
INTEGER*4 FIB$L_WCC
INTEGER*2 FIB$W_NMCTL
INTEGER*2 FIB$W_CNTRLFUNC
INTEGER*4 FIB$L_CNTRLVAL
END STRUCTURE
RECORD /FILEINFO/ FILE_INFO
C
C SET NO ERROR
C
ERR = 0
C
C ASSIGN THE DISK
C
LDISK = INDEX(DISK,' ')-1
STATUS = SYS$ASSIGN(DISK(:LDISK),DISK_CHAN,,)
IF(.NOT.STATUS) THEN
STATUS=LIB$SIGNAL(%VAL(STATUS))
ERR = 1
GOTO 999
ENDIF
C
C MODIFY QUOTA
C
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
FILE_INFO.FIB$W_CNTRLFUNC = FIB$C_MOD_QUOTA
FILE_INFO.FIB$L_CNTRLVAL = FIB$M_MOD_PERM
DESC(1) = 28
DESC(2) = %LOC(FILE_INFO)
DF(1) = 32
DF(2) = %LOC(QF)
C
STATUS = SYS$QIOW(,%VAL(DISK_CHAN),%VAL(IO$_ACPCONTROL),IOSB,,
+ ,DESC,DF,LFIELD,DF,,)
C
IF(.NOT.STATUS) THEN
STATUS = LIB$SIGNAL(%VAL(STATUS))
ERR = 1
GOTO 999
ENDIF
IF(IOSB(1).EQ.SS$_NODISKQUOTA) THEN
ERR = 1
WRITE(*,'(A)') ' No disk quota found on this disk'
GOTO 999
ENDIF
C
IF(QF(4).NE.NEW) ERR=2
999 CONTINUE
END
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.
DEFINE VERB SPACE
IMAGE "CERN$CERNEXE:SPACE.EXE"
PARAMETER P1,PROMPT="Users Name ",VALUE
PARAMETER P2,PROMPT="Group Name ",VALUE
QUALIFIER ADMIN, SYNTAX=ADMIN
QUALIFIER OUTPUT, VALUE(TYPE=$FILE,DEFAULT="SPACE.LIS")
QUALIFIER DISK, VALUE
QUALIFIER GIVE, VALUE(TYPE=$NUMBER)
QUALIFIER TAKE, VALUE(TYPE=$NUMBER)
QUALIFIER TO, VALUE
QUALIFIER FROM, VALUE
DISALLOW (TAKE AND NOT FROM)
DISALLOW (GIVE AND NOT TO)
DISALLOW (GIVE AND TAKE)
DEFINE SYNTAX ADMIN
IMAGE "CERN$CERNEXE:ADMIN.EXE"
PARAMETER P1,PROMPT="Group Name",VALUE
QUALIFIER OUTPUT, VALUE(TYPE=$FILE,DEFAULT="ADMIN.LIS")
A command to inspect and modify disk space allocations has been written using VMS System Services in FORTRAN 77.
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.