SYSRUTH@UTORPHYS.BITNET (06/19/87)
On our various systems here, we use base interactive priority 4, and have batch queues with priorities ranging from 1 through 4 (with CPU limits larger on the lower-priority queues). I believe that VMS' general scheduling algorithm is basically "a job at any given priority gets no CPU unless there is nothing waiting at a higher priority". *However*, every job at any p priority will get occasional CPU slices to try to ensure that low-priority\ jobs do not hold onto resources that higher-priority jobs need. I don't know if there is a consistent percentage, but I know that on a busy system like mine are, P1 jobs sometimes get no more than a few seconds of CPU between 10 and 6. In other words, lower-priority jobs really are. Having these queues is an excellent way to encourage people to submit jobs to soak up spare cycles and save money. I have never noticed any problems stemming from their use. Re: changing priority. If the batch queue has an associated priority, I believe that no-one without ALTPRI can raise the job's priority above that of the queue, regardless of the UAF value for that username. I believe this holds true for other UAF-settable values like CPU limit (this I know for sure), WSEXTENT, etc., although it may take a minimum for some of these. I for one believe having cheaper, lower-priority queues is a very good idea. Ruth Milner Systems Manager University of Toronto Physics SYSRUTH@UTORPHYS (BITNET)