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
>>>>