Well done, Tony.
NMD
 
On Mon, 22 Jan 1996, Tony Furnivall wrote:
 
> I, too, come late to the discussion on multiple job queues, which I
> have followed with much interest and great awe. It is a
> more complex subject than I originally envisaged, and I am
> impressed by the quality and quantity of comment the subject has
> drawn out. At any rate, here is my $0.02 on the topic.
>
> At present the system maintains a WAIT queue of jobs which are
> sequenced by  a priority (;INPRI=) and a time (correlating with
> the JobNum). Jobs where the ;INPRI exceeds a certain value (JOBFENCE)
> may be considered for launching. When the number of EXECuting jobs
> is less than the :LIMIT, the system selects the job with the highest
> ;INPRI and lowest JobNum, for launching. At all points the job is
> associated with this (unnamed) WAIT queue, because its presence
> as an EXECuting job effectively precludes the launch of another job.
>
> Let us apply this same concept to multiple, named INCLASSes.
> The system maintains a set of INCLASSes of jobs which are
> sequenced by a priority (;INPRI=) and a time (correlating with the
> JobNum). Jobs where the ;INPRI exceeds a certain value (JOBFENCE)
> may be considered for launching. When the number of EXECuting jobs
> associated with an INCLASS is less than the :LIMIT defined for the
> INCLASS, the system considers the job with the highest ;INPRI and
> lowest JobNum as a candidate for launching. Candidates represent an
> ordered set of jobs, sequenced by a priority (;INPRI=) and a time
> (correlating with the JobNum) ... and you can see where we are headed.
>
> It looks much prettier as a diagram, but what it boils down to is
> this. An INCLASS has three key values:
>
> a)  The maximum number of EXECuting jobs associated with the
>     INCLASS. This is set by  :LIMIT ...;INCLASS=<classid>
> b)  The actual number of EXECuting jobs associated with the
>     INCLASS. This is provided by the system.
> c)  The INPRI value needed for a job to be considered in the
>     scheduling process. This is set by :JOBFENCE;..;INCLASS= <classid>
>
> The INCLASS presents jobs to the main job launcher only when
> the number of jobs actually executing with this designator is
> *less* than the limit. Executing jobs may be attached to the
> INCLASS, and increase the second value, but do not affect the
> first value (set by a :LIMIT command).
>
> :ALTJOB <job>;INCLASS=<classname> operates differently for EXECuting
> jobs, and for WAITing jobs. For an EXECuting job it associates the
> job with a different INCLASS but does not otherwise affect the job
> or the INCLASS. For a WAITing job, it attaches the job to the set of
> WAITing jobs. At this point the job has an ;INPRI value and a JObNum
> value, which are the only considerations for membership in the
> WAIT section of the INCLASS.
>
> For an EXECuting job, ;INCLASS is rather like a maiden name - it
> tells something about your past, but does not directly affect your
> present. However, your present actions do affect your family
> of origin. Just so, the ;INCLASS associated with a job affects the
> ability of other jobs in the class to be presented for initiation,
> but does not otherwise affect any other running job.
>
> Summary:
> --------
>
> New thing called INCLASS (or JOBQ or whatever) which is affected
> by three commands.
>
> :LIMIT <classlimit>;INCLASS=<classname>
> :JOBFENCE <jobfencevalue>;INCLASS=<classname>
> :ALTJOB <jobid>;INCLASS=<classname>
>
> :LIMIT, :JOBFENCE without parameters would apply to the main
> overall system queue.
>
> Considerations:
> ---------------
>
> Associating an INCLASS with a User/Account is a neat way of providing
> a default INCLASS for jobs. However, as several people have pointed
> out, the unit of work is the JOB, not the USER or ACCOUNT.
>
> There is no need for INCLASSes to persist over system shutdowns. As
> Gavin has said, the simple act of applying a :LIMIT or :JOBFENCE
> to an INCLASS is sufficient to create it.
>
> Problems and solutions:
> -----------------------
>
> 1.  # of EXECuting jobs exceeds a class or system limit.
>
> This happens now - the test is whether or not there are *fewer*
> jobs than the limit, not whether there are *more* jobs than the limit.
> If there are more jobs than the limit, you just have to wait longer
> until enough jobs log off to fall below the limit. (Of course you
> can always up the limit!)
>
> 2.  ALTJOB of an EXECuting job into a different INCLASS may cause
>     INCLASS Limit to be exceeded.
>
> This happens now - at present upping the LIMIT is the only way to
> shoot yourself in the foot. Under this proposal you would have a
> double barreled shotgun - LIMIT and ALTJOB. There will always be a
> way to cause problems. We have urged HP repeatedly, in the past,
> to allow us to become masters of our own destiny. Why stop now?
> Caveat operator!
>
> 3.  How will the system handle conflicts in selecting the next job to
> run when there are many candidates?
>
> Highest priority job with lowest job number, just as at present.
> What we are really doing is staging the WAIT process. Just
> like the corral at a ski resort, or an amusement park.
>
> I feel better having gotten this off my chest, and look forward to
> seeing the outcome of our discussions at IPROF.
>
> Afterthought - this whole discussion is the most dramatic example I
> can imagine of two things:
>
> 1.  The power of the net when it comes to discussions like this
> and
> 2.  The willingness of Hewlett-Packard to listen to the needs of
>     their customers.
>
> I feel proud to be part of this community!
>