Hi,
I'm reluctanctly commenting... reluctanct because this topic has so many
areas that should be discussed, and priorities to resolve, that I think
a face to face meeting (IPROF) would be best.
On priority of jobs:
How about:
1) Job Queues are defined somewhere, somehow (possibly a simple flat
ASCII file, possibly via commands (e.g.: from SYSSTART or later)
(Whether or not the job queue definitions are permanent is not
relevant to this aspect of the discussion).
I don't mind having a "new queue" / "purge queue" / "alter queue"
command (not command file!) set, but would definitely prefer
a non-permanent data structure (speed of implementation,
flexibility of internals design). Also don't care for the "read a flat
file frequently" approach of Unix.
2) INPRI makes sense only within a job queue, not across job queues.
3) Each queue is limited independently of all other queues.
After all, the precise reason I want separate queues is to have
separate limits!
4) Perhaps no system-wide limit exists. If it does, then when a job
terminates from ANY queue, then the "pick next job" logic is:
scan queues in priority order (a queue attribute at creation time)
(queues with identical priorities are scanned in chronological
creation order).
First queue with a job ready to go, and queue has less than its
limit already running, gets picked.
Which job within the queue? The one with the highest INPRI (or,
in case of matching INPRIs, the "oldest" as today). (Note:
today, it isn't the true "oldest", but the oldest unchanged highest
INPRI.)
5) Each queue may, optionally, have a default workgroup associated with it.
For sites without Workload Manager, the "workgroup" allowed is only
CS, DS, or ES ... I.e.: dispatcher priority info.
6) If a newly introduced job in queue FOO lacks a workgroup on JOB card,
it inherits the queue's default workgroup (if any). If none, the
normal workload manager heuristics are used. Probably want to be
able to define a default workgroup for a queue like:
WORKGROUP=<workgroup name> [, <DEFAULT | ONLY> ]
ONLY would mean: can't be overriden by user (can be by operator).
7) SHOWJOB should sort by queue, then job# within queue.
8) Sessions should be independent of queues.
or:
Every queue has an attribute: TYPE = <BATCH | SESSION>
A queue with TYPE=BATCH is only for batch jobs, one with SESSION is
only for interactive sessions.
Coupled with a QUEUE= on the HELLO command, or a default session
queue for interactive logons,
this would allow sites to say "10 interactive users in ONLINE queue,
3 interactive users in SALES queue, 3 batch jobs in SALESWORK queue".
If a QUEUE= is allowed on the HELLO command, enforcement of any
restrictions like "salespeople may not use the OP queue" is left to
the student and/or system-logon UDCs/programs/tools.
Note that a default queue-per-user is easily extended to be two
default queues: one for HELLO (session), one for JOB (batch).
My basic philosophy is: simple, powerful, flexible, extendable. HP doesn't
have to implement the world's best queueing mechanism ... a good basic
mechanism plus hooks for extension would be fine.
Hooks:
No matter what queue structure is eventually picked, even if *none* is,
the JOB process should have a new AIF:PE interceptable routine it calls:
select_next_job_to_start (var status : hpe_status;
var js_num : integer (or js_num_type?));
var none_ready_to_start : boolean);
(all are output parameters)
This single concept would immediately open the door up to efficient
CSL and third party job schedulers.
--
Stan Sieler [log in to unmask]
http://www.allegro.com/sieler.html
|
