Subject: IPP>MOD Re: "Held" is not Active [Ok if I don't include pendingHeld in "active" jobs?]

From: [email-masked] (Robert Herriot)
Date: Mon, 9 Jun 1997 12:43:29 -0700

The email from the JobMIB group about the pending-held state made
me realize that getJobs works differently depending on whether
pending-held is a true state or just a sub-state of pending.

GetJobs has a parameter for specifying the states of jobs to be returned
and the order of these states determines the order of returned jobs.

If pending-held is a sub-state, then a getJobs of jobs in the pending
state will return all pending jobs whether held or not and they will
be in the returned in order of printing.  Thus, for example, if it is 4:50pm,
a job that is held until 5pm may come before a job that is pending.

If pending-held is a true state, then the parameter for getJobs must
specify both pending and pending-held to get such jobs and the client
must specify an order.

If processing-stopped is a true state, then a client must specify both
processing and processing-stopped to get processing jobs, because it doesn't
know whether such jobs are stopped.

Bob Herriot

> From [email-masked] Mon Jun  9 08:13:48 1997
> X-Sender: hastings@zazen
> X-Mailer: Windows Eudora Pro Version 2.1.2
> Mime-Version: 1.0
> X-Priority: 2 (High)
> Date: Mon, 9 Jun 1997 08:07:15 PDT
> To: [email-masked], Harry Lewis <[email-masked]>
> From: Tom Hastings <[email-masked]>
> Subject: Re: JMP> Re: "Held" is not Active [Ok if I don't include
>   pendingHeld in "active" jobs?]
> Sender: [email-masked]
> X-Lines: 148
> 
> I agree that the jmGeneralNumberOfActiveJobs shouldn't count jobs
> in the pendingHeld state so that the user gets a better idea of how
> busy the printer is from the value of jmGeneralNumberOfActiveJobs.
> 
> However, what about our two indexes which also include
> the active jobs.  Here is isn't so clear whether the
> jmGeneralOldestActiveJobIndex should or should not include the pendingHeld
> jobs.  The advantage of not including them, is that they tend to get "stuck"
> amongst a lot of completed jobs in the table, so that an application would
> have to skip over a growing number of completed jobs.
> 
> >jmGeneralNumberOfActiveJobs Integer32(0..2147483647),
> >jmGeneralOldestActiveJobIndex Integer32(0..2147483647),
> >jmGeneralNewestActiveJobIndex Integer32(0..2147483647),
> 
> For example, at 10:00Am when I submit the job that is held until 5:00 pm
> the table might look like:
> 
> jmJobIndex   State
> 200          completed
> 201          completed
> 202          completed
> ...
> 330          completed
> 331          processing             <-- jmGeneralOldestActiveJobIndex
> 332          pending
> 333          pending
> 334          pendingHeld  - my job  <-- jmGeneralNewestActiveJobIndex
> 
> At 12:00 AM the table might look like:
> 
> 334          pendingHeld            <-- jmGeneralOldestActiveJobIndex
> 450          completed
> 451          completed
> 452          completed
> ...
> 597          completed
> 598          processing
> 599          pending
> 600          pending
> 601          pending                <-- jmGeneralNewestActiveJobIndex
> 
> So the applications would have to skip over the 150 or so completed jobs.
> 
> If we define active as no including pendingHeld, then we get:
> 
> At 12:00 AM the table might look like:
> 
> 334          pendingHeld
> 450          completed
> 451          completed
> 452          completed
> ...
> 597          completed
> 598          processing             <-- jmGeneralOldestActiveJobIndex
> 599          pending
> 600          pending
> 601          pending                <-- jmGeneralNewestActiveJobIndex
> 
> This is better for most applications.  An application that wants to show
> the entire queue to an operator will have to search through all the
> jobs looking for pendingHeld jobs.  But maybe that is a good tradeoff.
> Such an application is likely to be keeping a copy of the table anyway.
> 
> Note that at 5:00 pm, the agent has to cause the jmGeneralOldestActiveJobIndex
> to be set back to 334, when my job changes from pendingHeld to pending.
> 
> Also note that an implementation that moves pending jobs to pendingHeld
> when the resources are changed on the device will have to fiddle with
> jmGeneralOldestActiveJobIndex as well, to keep it pointing at the oldest
> active job.
> 
> So I'll change the definition of active to not include pendingHeld.
> (and remove the active in-active from the picture, since it doesn't
> cleanly divide.
> 
> 
> At 14:02 06/06/97 PDT, Harry Lewis wrote:
> >The problem I have with held meaning active is that is messes up the concept of
> >"number of intervening jobs". If I'm testing the waters at 9am for a printer
> >with least number of intervening jobs, I will get a false impression if the
> >printer tells me about all the jobs which are held until midnight.
> >
> >I think held jobs are, indeed, inactive.
> >
> >>>> Harry Lewis <<<
> >
> >
> >------ Forwarded by Harry Lewis/Boulder/IBM on 06/06/97 02:43 PM ------
> >
> >        [email-masked]
> >        06/05/97 07:00 PM
> >Please respond to [email-masked] @ internet
> >
> >
> >To: Harry Lewis/Boulder/IBM@IBMUS
> >cc: [email-masked] @ internet
> >Subject: JMP> Re: "Held" is not Active
> >
> >I don't remember the discussion.
> >
> >The definition of which job states include "active" has affect on the
> >following objects:
> >
> >jmGeneralNumberOfActiveJobs Integer32(0..2147483647),
> >jmGeneralOldestActiveJobIndex Integer32(0..2147483647),
> >jmGeneralNewestActiveJobIndex Integer32(0..2147483647),
> >
> >I had assumed that the fact that a job was in the 'held' state still
> >meant that it would be included in the jmGeneralNumberOfActiveJobs,
> >since 'held' is just a variant of the 'pending' state
> >(though you could make an argument that a held job isn't as likely
> >to be processed as other jobs that are pending and so shouldn't be included
> >in the count of active jobs which is an indication of the business of the
> >printer).
> >
> >On the other hand, an application that is using the OldestActiveJobIndex
> >might not want to miss jobs that are in the 'held' state.  Similarly,
> >when an idle printer accepts a job that is in the 'held' state, I don't think
> >we want the agent to keep the NewestActiveJobIndex at 0.
> >
> >So I thought it was simpler to include 'held' jobs as active.  So all the
> >states on the left of the picture are the "active" states, and the
> >three terminal states on the right of the picture are in-active states.
> >
> >Ok?
> >
> >Tom
> >
> >At 10:16 06/05/97 PDT, Harry Lewis wrote:
> >>Tom,
> >>
> >>>So how does this picture look to you for IPP and JMP (IPP wouldn't
> >>>have the enums and wouldn't have the "active/in-active" line, since
> >>>it is a JMP-only term).
> >>
> >>I thought we agreed, in Austin, that Held was not Active.
> >>
> >>Harry Lewis - IBM Printing Systems
> >>
> >>
> >
> >
> >
> >
> >
> >
> 
>