On Wed, 10 Jan 1996, Jim Wowchuk wrote:
 
> NO, NO, NO!!!  Just as a user can use multiple printer queues, they should
> have access to multiple job queues.  Alter the :STREAM and !JOB commands
> accordingly to accept optional INPUTQ parameters.  If not INPUTQ is
> specified, then use the system default.
 
  Hmm.. This idea of allowing/restricting users to certain queues doesn't
sit well with me.  Instead, why not divy up the queues according to
resource needs and usage, such as the CXbatch system of ConvexOS.
 
  For example, you can set up queues to limit memory and disk usage of
the job to 50MB and have higher priority (why not let the job execute
faster... it's not consuming resources to slow everything else down?)
than the bigger, bulkier, CPU intensive, long term jobs.
 
  You can create larger queues to handle bigger jobs, but these jobs will
be reprioritized under the smaller jobs that require less CPU time, and
hence can be gotten out of the way first to allow more time for the
bigger job.
 
  The example given about reprioritizing COBOL/program compiles to lower
queues over Oracle DB systems isn't really 'fair' to the employee, as
each person, I assume, has their own deadlines.  If you prioritize
according to resource needs (and if job requires more resources than
allotted by queue, it's dumped) then short term, small jobs won't be
sitting around waiting for CPU time from big intensive jobs, and more
people can get their work done.
 
> >3. Job limit - Maximum number of active jobs for this queue.
> Yes.
 
  Why not have some sort of dynamic active limit?  Again, if there are lots
of little jobs, execute them to get them out of the way, provided that
they meet the queue resource limits.  With multiple jobs though, then you
could start divying up CPU time, as someone could flood the queue and
hence take away CPU time from other lower priority database jobs (for
example).
 
> >   The max.  number of jobs  specified  by  :LIMIT  command  indicates  the
> >   system  wide  limit.  At any  point  of time the  number  of jobs in the
> >   system cannot exceed this limit.
>
> Again, just as the JOBFENCE command alters particular limits, the behaviour
> for the LIMIT should be enhanced the same way.
 
  Agreed there... why have system wide link when the operator could more
effectively and efficienty address each queue individually without having
to worry about system constraints.  If you do have system constraints,
you may be able to allow certain groups or account managers to set up
their own queues.  The SM/OP would provide queue resources to the AM, who
in turn sets up the queues for his account/groups as he sees fit they
spend their resources.  The SM/OP would still set up system wide queues
of course.
 
 
  I will say it's fun to give feedback to the HP people. :)
 
Daniel Kosack  -- Linux Man --
[log in to unmask]
 
  --Nothing is ever impossible.  Imagination and improvisation are the key.