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 hastings@cp10.es.xerox.com 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: jmp@pwg.org, Harry Lewis <harryl@us.ibm.com>
> From: Tom Hastings <hastings@cp10.es.xerox.com>
> Subject: Re: JMP> Re: "Held" is not Active [Ok if I don't include
> pendingHeld in "active" jobs?]
> Sender: jmp-owner@pwg.org
> 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 ------
> >
> > jmp-owner@pwg.org
> > 06/05/97 07:00 PM
> >Please respond to jmp-owner@pwg.org @ internet
> >
> >
> >To: Harry Lewis/Boulder/IBM@IBMUS
> >cc: jmp@pwg.org @ 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
> >>
> >>
> >
> >
> >
> >
> >
> >
>
>