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

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

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

Tom Hastings hastings at cp10.es.xerox.com
Wed May 21 02:11:18 EDT 1997

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-hold-until-specified                  job-hold-until-specified
required-resources-not-ready              required-resource-not-ready

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.


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

More information about the Ipp mailing list