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