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