Hi Sue, there are two main ways you could address this with PBS Pro.
You can set limits on the total number of jobs individual users/groups can have at the server or queue level (max_queued, max_queued_res). These allow complex values limiting the job/resources for all user/groups in total, all individual users/groups, or special limits for individual users/groups.
If you didn’t want to actually limit the total number of jobs people can submit but simply thwart “queue stuffing” you can look into the eligible wait time concept. Whether or not this would be useful depends on your overall scheduling policy, specifically how a job’s waiting time increases the priority vs. just simple FIFO. I’ll just copy and paste a couple of parts from the Admin guide here (there are many more details of course):
PBS provides a method for tracking how long a job that is eligible to run has been waiting to run. By “eligible to run”, we mean that the job could run if the required resources were available. The time that a job waits while it is not running can be classified as “eligible” or “ineligible”. Roughly speaking, a job accrues eligible wait time when it is blocked due to a resource shortage, and accrues ineligible wait time when it is blocked due to project, user, or group limits.
A job accrues ineligible_time while it is blocked by project, user, or group limits, such as:
A job also accrues ineligible_time while it is blocked due to a user hold or while it is waiting for its start time, such as when submitted via
qsub -a …
A job accrues eligible_time when it is blocked by a lack of resources, or by anything not qualifying as ineligible_time or run_time. A job’s eligible_time will only increase during the life of the job, so if the job is requeued, its eligible_time is preserved, not set to zero. The job’s eligible_time is not recalculated when a job is qmoved or moved due to peer scheduling.
I hope this helps.