JMP> Re: IPP> MOD JobState suggestion

JMP> Re: IPP> MOD JobState suggestion

Tom Hastings hastings at cp10.es.xerox.com
Thu Jun 5 11:39:02 EDT 1997


I agree completely with Harry that we should have seven job states
for IPP and JMP.


I also happen to like the simpler single word names for the 7 states:


pending
held
processing
stopped
canceled
aborted
completed


My understanding from the 6/4 telecon is that the JMP jmJobState object
will remain in the MANDATORY jmJobTable and that we will use Ron's suggestion
for the conformance of the enums as:


 "All possible enums for this object must be reported if implemented and 
  available to the agent."


And then I agree with Harry that JMP implementations can use as many or as
few job-state-reasons to embellish these states.  My understanding of our
agreement yesterday (6/4 telecon) is that JMP will keep jmJobStateReasons1 
object MANDATORY, but not say anything about which enums are MANDATORY, 
which are CONDITIONALLY MANDATORY and which are OPTIONAL.  Correct?


Or should we include Ron's statement for JMP jmJobStateReasons1 object
as well?




IPP has job-state-reasons attribute as MANDATORY and has the following
job-state-reason values MANDATORY, CONDITIONALLY MANDATORY, and OPTIONAL: 


MAN  none
MAN  job-incoming
OPT  outgoing
COND job-hold-until-specified
OPT  job-hold-until-resources-are-ready
OPT  printer-stopped-partly
MAN  printer-stopped
OPT  job-printing
MAN-L2 job-canceled-by-user
MAN-L2 job-canceled-by-operator
OPT  logfile-pending
OPT  logfile-transferring
MAN  job-completed-successfully
MAN  job-completed-with-warnings
MAN  job-completed-with-errors


Tom




At 14:05 06/04/97 PDT, Harry Lewis wrote:
>I also want a small set of meaningful job states.
>
>>A job can be in many, many kinds of "states", depending on the features
>>(and attendant complexities) of the underlying printing system.  However,
>>no matter what printing system is involved, all jobs will be in exactly
>>one of the three top-level "meta" states of pending, processing, done.
>
>>Below these three states, the mgmt application in question will decide
>>on the exact semantics of the job based on some *consistent* refinement
>>of the top-level state.  Hence, the simple two-level model I have been
>>suggesting this past week or so.
>
>> ...jay
>
>I tend to get very confused by the 3 separate terminology's however,
>those being JobState, JobSubState and JobStateReason.
>
>I believe there are actually 7 job states that deserve to be called
>STATES. We should be welcome to embellish any state with as many (or as
>FEW) REASONS as seen fit. Listed in my preferred terminology along with
>the current IPP/JMP name-for-a-day in parenthesis, the 7 are:
>
>Pending
>Held (Pending-Held)
>Printing (Processing)
>Needs_Attention (Processing-Stopped)
>Completed
>Canceled (Completed-Canceled)
>Aborted (Completed-Aborted)
>
>Yes, the STRAIGHT LINE PATH from submission to marks on paper is
>Pending-Printing-Complete, but other significant states are Held,
>Needs_Attention, Canceled and Aborted. There are all kinds of reasons
>(my favorite being printer-partly-stopped). I would like to suggest, however,
>that if we adopt these 7 as the "high level" states then we can eliminate the
>idea of "sub-state".
>
>Harry Lewis - IBM Printing Systems
>
>



More information about the Ipp mailing list