Harry,
I agree with your position 100%. We spent considerable time developing
the three state model and, in spite of the "caboodle" of state reasons,
does map very well into a real environment.
Keeping the job state at "Processing" for this transient period is merely
a small change to the model and shoukd not be difficult for a printer to
report or a management application to process.
Ron Bergman
Dataproducts Corp.
On Wed, 10 Sep 1997, Harry Lewis wrote:
> Ira, I could live with a new state if we were in the early stages of this MIB.
> In the beginning I argued for a succinct list of STATES rather than a caboodle
> of catagorized state reasons. But, long ago, we landed on a limited set of
> states and many, many reasons. We're in the tweaking stage, now, just trying to
> lay down some interoperability regarding use of what we have. I think adding a
> state at this point is too big a change.
>> I believe we're expending a lot of energy to solve a very transient condition -
> the admittedly short time between a CANCEL request and a CANCEL (completed)
> state change. I don't think it's necessary, especially in light of the fact
> that we have state reasons such as... canceledByOwner, canceledByOperator,
> porcessingToStopPoint etc.
>>> Harry Lewis - IBM Printing Systems
>>> ---- Forwarded by Harry Lewis 09/10/97 05:23 PM ----
>>>ipp-owner at pwg.org on 09/10/97 02:23:54 PM
> Please respond to ipp-owner at pwg.org @ internet
> To: jmp at pwg.org @ internet, ipp at pwg.org @ internet, hastings at cp10.es.xerox.com> @ internet
> cc:
> Subject: IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state sema
>>> Hi Tom,
>> After reading all that (excellent writeup, by the way), I begin to
> like adding the clean and unambiguous 'terminating' state (from
> ISO DPA), so that leading/trailing edge changes ALWAYS result
> in a state change (and thus a notification or event, if possible)
> and a client need not examine state reasons to determine if an
> operation is legal at the present moment.
>> Harry, could you live with a 'cleanup' state on the switchbar
> of the three terminal states? It sure makes notifications (or
> SNMP traps) a lot cleaner and simpler.
>> Cheers,
> - Ira McDonald (outside consultant at Xerox)
> High North Inc
> PO Box 221
> Grand Marais, MI 49839
> 906-494-2434
> ---------------------------------- Tom's note ----------------------
> From jmp-owner at pwg.org Wed Sep 10 12:00:41 1997
> Return-Path: <jmp-owner at pwg.org>
> Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com
> (4.1/XeroxClient-1.1) id AA08378; Wed, 10 Sep 97 12:00:40 EDT Received: from
> alpha.xerox.com by zombi (4.1/SMI-4.1) id AA04249; Wed, 10 Sep 97 11:56:03 EDT
> Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com with
> SMTP id <53682(1)>; Wed, 10 Sep 1997 08:56:52 PDT Received: from localhost
> (daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA26321
> for <imcdonal at eso.mc.xerox.com>; Wed, 10 Sep 1997 11:53:21 -0400 (EDT) Received:
> by pwg.org (bulk_mailer v1.5); Wed, 10 Sep 1997 11:51:51 -0400 Received: (from
>daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA26189 for
> jmp-outgoing; Wed, 10 Sep 1997 11:50:25 -0400 (EDT) Message-Id:
> <9709101550.AA22451 at zazen.cp10.es.xerox.com> X-Sender: hastings at zazen X-Mailer:
> Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain;
> charset="us-ascii" Date: Wed, 10 Sep 1997 08:47:43 PDT To: ipp at pwg.org,
>jmp at pwg.org From: Tom Hastings <hastings at cp10.es.xerox.com> Subject: JMP> MOD -
> 'canceled' and 'aborted' job state semantics Sender: jmp-owner at pwg.org Status: R
>> There has been a good discussion in both the IPP and JMP DL about
> the semantics of the 'canceled' state: whether the job moves to
> 'canceled' state immediately upon acceptance of the Cancel-Job operation
> or whether the job moves to the 'canceled' state when the canceling has
> completed and the job is quiescent (all the job accounting counters have
> stopped counting, and all the media sheets are stacked).
>> Usually the time difference is just a few seconds after the Cancel-Job
> operation has been accepted, but in some implementations the time could be
> considerably longer than a few seconds, including fixing a paper jam or
> paper out.
>> The same discussion also applies to when the system aborts a job.
> Does the job move to the 'aborted' state immediately, or when the
> system finishes aborting the job?
>> The 'completed' state is specified as being reached when all of the
> processing, including "media sheets successfully stacked", so that the
> 'completed' state is reached after the job is quiescent.
>> It is hoped that we could discuss this issue at the IPP telecon today
> and continue and resolve it at the IPP meeting next week in Atlanta
> (with JMP participation). We need to keep both specs in synch.
>>>> The issue is whether to continue the current IPP and JMP semantics:
>>> A. Leading Edge Job State Transition:
>> 1. The job changes immediately to the 'canceled' or 'aborted' states
> from the 'processing' state with the 'processing-to-stop-point'
> and 'canceled-by-xxx' reasons set.
>> 2. WHEN the canceling or aborting is complete the 'processing-to-stop-point'
> job state reason is removed (but the job state doesn't change since
> the job is alread in the 'canceled' or 'aborted').
>>> OR change the IPP and JMP semantics to:
>>> B. Trailing Edge Job State Transition:
>> 1. The job remains in 'processing' with 'processing-to-stop-point'
> and 'canceled-by-xxx' OR 'aborted-by-system' reasons set.
>> 2. WHEN the canceling or aborting is completed the 'processing-to-stop-point'
> is removed AND the job transitions to the 'canceled' or 'aborted' state
> with either 'canceled-by-xxx' or 'aborted-by-system' remaining.
>> (Actually, the 'aborted-by-system' is redundant with the 'aborted' state,
> but if there every is another reason to abort a job, it may be good
> to keep 'aborted-by-system' as a reason. In JMP 'aborted-by-system'
> is also useful in the pending-held state for systems that chose to
> allow a user or operator to release a job that has had a problem,
> perhaps after modifying the job or the environment).
>>>>> PROs and CONs:
>>> 1. The 'canceled' and 'aborted' states become quiescent states, like
> the 'completed' state already is.
>> The advantage of Trailing Edge Job State Transition is that the three
> terminal states: 'completed', 'canceled', and 'aborted' would be
> all quiescent state.
>> With the Leading Edge Job State Transition semantics, 'completed' is
> quiescent, and 'canceled' and 'aborted' are not.
>>> 2. Easier rejection of operations: just use the job state, not the reasons
>> The advantage of the Leading Edge Job State Transition is that it
> is clearer when operations are illegal: only the job states are involved.
> This is the classis job state transition diagram showing operations
> and job state transitions.
>> So once a Cancel-Job has been issued, a subsequent Cancel-Job returns an error
> that the job is in an inappropriate state whenever the job state
> is 'completed', 'canceled', or 'aborted'.
>> With the Trailing Edge Job State Transition, the user and the Printer
> have to look at both the job state and the job-state-reasons in order
> to reject multiple Cancel-Job operations and the job state transition
> diagram is more complicated.
>>> 3. Better notification/trapping when job is quiescent
>> The advantage of Trailing Edge Job State Transitions is that an application
> program, such as an accounting program, that gets a notification or trap
> on job state transitions, will get the notification or trap on entering
> the 'completed', 'canceled', or 'aborted' state AFTER all the processing
> has completed and all the counts have finished counting, so that polling
> can be avoided for any additional processing to stop point activity.
>> Also the job state reflects the completion of an operation, not just the
> acceptance of the operation for those operations that are not performed
> before the response is returned, such as Cancel-Job, when the job is
> in the 'processing' state.
>> NOTE: IPP has notification, but JMP does not have SNMP trapping, though
> all of the priviate job MIB do (IBM, HP, Xerox, Dataproducts?)
>>>> E-MAIL conclusion:
>> The e-mail discussion seems to favor changing the IPP and JMP semantics
> to "Trailing Edge Job State Transition" semantics, since many protocols
> use states to mean that the operation has finished all of its work.
> Also reducing polling seems to be more important than simplfying the Printer
> implementation and the job state transition diagram when legal operations
> are shown.
>> *******************************************************************
> We need to see if the rest of the IPP and JMP participants agree
> to change the spec to Traling Edge Job State Transition semantics.
> *******************************************************************
>>> Probably neither side would be happy with a compromise that complicates
> the state model by adding a new Job state: 'terminating' (the name
> used for the ISO DPA job state). Then the 'processing-to-stop-point' reason
> would not be needed for this.
>> With such a compromise, there would be a job state transition when the
> Cancel-job operation is accepted (leading edge transition from 'processing'
> to 'terminating') and when the operation completes
> (trailing edge transition from 'terminating' to 'completed',
> 'canceled', or 'aborted'). The Cancel-Job operation would be rejected
> when the job was in the 'terminating' job state (as well as when in the
> 'completed', 'canceled', and 'aborted' job states).
>>> Comments?
>> Tom
>>>>>