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