IPP Mail Archive: Resend: IPP> Resolving IPP/JMP job-state and job-state-reasons

Resend: IPP> Resolving IPP/JMP job-state and job-state-reasons

Tom Hastings (hastings@cp10.es.xerox.com)
Wed, 21 May 1997 07:07:24 PDT

I wasn't very clear in my previous reply to Bob (attached)
about why there is a need for the generic job-held reason
to indicate that the job isn't a candidate for scheduling. We only need the
job-held reason, IFF there are any reasons in the pending state that are not
holding up the job. In IPP, the reasons: job-sending-to-output-device
and job-queued-in-output-device are reasons that the job is in the pending
state, but is not being held up. So an application program that is flagging
jobs to its user that are not candidates for processing (i.e., are being held),
would NOT want to flag a job that was being sent to the output device or was
already queued in the output device.

Since IPP has a need for the generic job-held reason, so does JMP.

Tom

At 23:11 05/20/97 PDT, Tom Hastings wrote:
>I agree with Bob's suggestions for both IPP and the Job Monitoring MIB
>for simplifying the job-state and using job-state-reasons to indicate
>information about the state.
>
>I have a refinement concerning the job-held reason.
>
>If a job has no reasons that jobs are held in the pending state, then
>the job-held reason need not be implemented at all.
>
>If an implementation has only one reason that jobs are held while in the
>pending state, then that implemenation shall implement and return at least
>the job-held reason. However, if there are several reasons, then that
>implementation shall implement (and return) the job-held reason
>*in combination* with the other more specific reason(s). Then an application
>that doesn't understand all the reasons that jobs can be held, can at least
>know that the job isn't going to be scheduled if the job-held reason is
>present (and perhaps flag that job in some distinguishing way to its user).
>
>The additional more-specific reasons for holding a job are:
>
> IPP JMP
>job-incomplete becoming: job-spooling?
>job-sending-to-output-device
>job-queued-in-output-device
>job-hold-until-specified job-hold-until-specified
>required-resources-not-ready required-resource-not-ready
> documents-needed
> job-hold-set
> job-process-after-specified
> job-pre-processing
> job-paused
> job-interrupted
> ...
>
>I think that the IPP reasons need review, and then should be added to JMP.
>The JMP reasons do not need to be added to IPP though, since JMP is attempting
>to monitor other systems in addition to IPP.
>
>Tom
>
>
>At 12:01 05/20/97 PDT, Robert Herriot wrote:
>>
>>Good analysis Tom.
>>
>>The following is my opinion on what should change to align IPP and JobMIB.
>>I think that IPP and the JobMIB each offer some good ideas.
>>
>>I would like to keep the job states very simple and make sure that
>>they go in a simple progression with detours handled by job-state-reasons.
>>We mostly did that in IPP, but the JobMIB did a better job at the end of
>>the job.
>>
>>I suggest that the IPP (and JobMIB) state progression be:
>>
>> ---> completed
>>pending -> processing - |
>> ---> canceled
>>
>>Even though canceled could be handled by a job-state-reason under completed,
>>I think that it is an important reminder that the job didn't complete
>>for some reason, hopefully explained in the job-state-reasons.
>>
>>This means that there are the following job-state-reasons:
>>
>> o job-held during the pending state
>> o printer-stopped during the pending or processing state
>> o job-retained during the completed or canceled state.
>>
>>It also means that the follow IPP states go away:
>>
>> o terminating becomes canceled which has a longer duration
>> o retained becomes a job-state-reasons job-retained
>>
>>I would prefer that both IPP and the JobMIB adopt these states. It
>>requires changes for both, but I think it is a better solution than
>>either currently offers.
>>
>>Bob Herriot
>>
>>
>>
>>
>
>
>