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 at pwg.org> 06/05/97 07:00 PM
>Please respond to jmp-owner at pwg.org @ internet
>>>To: Harry Lewis/Boulder/IBM at IBMUS>cc: jmp at 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
>>>>>>>>>>