IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state semantics

IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state semantics

IPP> Re: JMP> MOD - 'canceled' and 'aborted' job state semantics

Ira Mcdonald x10962 imcdonal at eso.mc.xerox.com
Wed Sep 10 13:05:48 EDT 1997

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.

- Ira McDonald (outside consultant at Xerox)
  High North Inc
  PO Box 221
  Grand Marais, MI  49839
---------------------------------- 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 ([]) 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).



More information about the Ipp mailing list