Xref: utzoo comp.os.vms:8748 comp.unix.wizards:11188
Path: utzoo!attcan!uunet!husc6!cmcl2!rutgers!ucsd!ucsdhub!jack!elgar!crash!jeh
From: jeh@crash.cts.com (Jamie Hanrahan)
Newsgroups: comp.os.vms,comp.unix.wizards
Subject: Re: VMS vs. UNIX file system
Summary: Why VMS quotas
Keywords: quota
Message-ID: <3441@crash.cts.com>
Date: 17 Sep 88 17:49:44 GMT
References: <411@marob.MASA.COM> <178@arnold.UUCP>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Followup-To: comp.os.vms
Organization: CMKRNL Press, San Diego, CA
Lines: 41

In article <178@arnold.UUCP> dave@arnold.UUCP (Dave Arnold) writes:
>How often have you written a program, and got the famous:
>
>%SYSTEM-F-EXCEEDED QUOTA
>
>message?  Isn't it fun trying to figure out which bloody quota
>was exceeded?!  Stupid!

Apologies for the cross-followup to the unix group; I don't know if
Dave reads the VMS group.  

The VMS quota system has two good reasons for being.  First, it prevents
a runaway program from using up all of something that might be in short
supply, like nonpaged pool or process slots.  Without this you could sit
in a loop doing $QIO with no wait to an offline device, and you'd bother
everybody on the system.  With quotas in effect you only bother yourself.
You can always enable process resource wait mode, which will cause your
process to go into MWAIT state (usually seen, for this purpose, as RWAST)
until the needed quota is returned, presumably by the completion of a 
previously-requested operation.  (Process resource wait mode is enabled
by default.)

You can also get EXQUOTA if you try to do a buffered I/O operation that's
larger than the size permitted by the SYSGEN parameter MAXBUF.  This is a
common pitfall.  MAXBUF is only middling-sized by default (somewhere near
1K if I recall correctly).  Many sites routinely set this up to 8K or so,
especially those that have megabytes of pool available.  

The other purpose of the quota system is to make sure that everything 
you've started is finished before your image is allowed to run down.  
Say you start a direct I/O operation to a flaky device driver; the system
charges your DIOLM by one.  You wait and decide to ^Y out, but the driver's
cancel I/O code doesn't work right so the I/O doesn't get aborted.  The
system notes that the original DIOLM is different from the current value
and won't permit your image to run down until they're the same.  This is
one of the great banes of both system managers and driver writers, but it's
necessary much of the time; if that I/O op is a read, and it decides to 
complete AFTER your image has run down and the physical pages you used 
to own (and to which the DMA will be performed) get assigned to somebody
else, watch out!  It's impossible for the system to distinguish where this
is necessary and where it isn't, so it's done all of the time.