Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!RITA.ACS.WASHINGTON.EDU!WIZARD From: WIZARD@RITA.ACS.WASHINGTON.EDU (The Bandit "." "." "." "", on" "RITA) Newsgroups: comp.os.vms Subject: RE: Re: Performance and batch jobs. Message-ID: Date: 20 Dec 87 21:55:00 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 52 Rahul Dhesi responded to my recent message with two comments. It seems I needed to take more care to ensure that my messages are clear. > A good solution to this is to make SYS$SCRATCH point to a device with > plenty of scratch disk space, and to have a batch job clean out old > files every 15 minutes. Although this suggestion appears to be good, and in many environments would probably do the trick, it doesn't suit our needs. As mentioned, the user was over his disk quota by quite a lot. Typically, our users get a scant 750 to 1500 blocks of disk quota. This is because we have many many users, and limited disk space. We don't have any disk with plenty of disk space. Our approach is as follows. I mentioned in my earlier message that the compilers are installed with EXQUOTA, but I failed to mention that our editors are also installed with EXQUOTA. This allows the students to edit and edit and edit (as well as to compile and compile and compile) until they get a program which compiles with no errors. By doing this, the student can save multiple backups of his/her programs in order to back out an unwise change. However, once the program compiles with no errors, the student MUST clean up his/her directory in order to proceed. Since most students are learning to program, as well as learning VMS, this seems to help them the most by keeping VMS problems out of their way until they have finished dealing with programming problems. ******************************************************* The second comment made was: > It [a zero-priority job] certainly ought not to bring the system down, > unless the amount of disk space set aside for swapping is not enough--and > if so, a well-designed system will simply abort the job with an > out-of-memory or out-of-swap-space error message. > ... > but I had expected VMS to be better able to protect itself from this. I believe my choice of the word "died" here was deceptive. I meant that these jobs brought the system to its knees. It was essentially thrashing itself to death with page-faults. VMS does handle this situation OK, however. I understand that in VMS V5.0 there are changes to be made to the job scheduler to address this particular problem. Low(er) priority jobs will have all of their memory taken away in order to service jobs with higher priorities. They simply won't get any memory until there is enough idle time to do anything for it. Sorry for the confusion. Derek Haining