Paul H. Christidis writes:
 > I'm very pleased that you've decided to elicit comments/suggestions from
 > the folks that this would effect the most. Bravo!!
 
Thanks Paul.
 
[snip]
 
 > 2.  Having a configuration file to control user membership could
 > potentially cause administrative nightmares.
 
It is a question of whether to have a config file or have commands to
do the job. Basically, cost vs. ease-of-use.
 
 > 3.  Too many *new* commands are being proposed. I would much rather see the new
 > queues being controlled by additional parameters to the STREAM, JOB, ALTUSER,
 > SHOWJOB, etc commands.  If integration into existing commands is not possible
 > then something as :JOBQ <queuename>;[delete|build|change|show|...];.... would b
 > e
 > preferable.  A single command would have the advantage of centralizing the help
 > documentation and would facilitate any future extensions.
 
Point taken.
 
 > 4.  You current proposal, I feel, only would address the situation where we
 > want, for example, to let our accounts payable application have 3 job slots and
 > our human resources have 1 job slot.  It does not address the situation where w
 > e
 > may want to run one *long* running job at the same time with two medium and
 > three short duration jobs.  Perhaps thought should be given to *job classes*
 > where certain CPU thresholds correspond to each job class, to keep the users
 > honest, and the dispatcher launches jobs across the multiple queues taking the
 > job class into consideration.
 
I think what you are suggesting is to have an explicit mechanism to
specify which class the job belongs to, so that it will go to an
appropriate queue. If so, please see my response in the other mail in
this thread where I have mentioned why we thought that won't be a
feasible option.
 
 > I thank you for the opportunity to comment on your proposed enhancement and hop
 > e
 > that you get *lots* of feedback and suggestions from the user community.
 
Thank you for your feedback.
 
Best regards,
mohan