Harry has nailed the solution on the head.
Also, we can add as many reasons as we need to to support all of these
different configurations.
Scott
>>> Harry Lewis <harryl at us.ibm.com> 09/03 10:00 AM >>>
Ira, I hope we can satisfy both our concerns by recognizing that job state
reasons are bits and there can be more than one
reason at a time. So, in the Processing state, the reasons can be
"processingToStopPoint" and "canceledByUser". I would prefer this as the
interoperable model as opposed to insisting the CANCEL state be entered
immediately.
Harry Lewis - IBM Printing Systems
---- Forwarded by Harry Lewis/Boulder/IBM on 09/03/97 09:46 AM ----
imcdonal at eso.mc.xerox.com on 09/02/97 09:51:55 AM
Please respond to imcdonal at eso.mc.xerox.com @ internet
To: jmp at pwg.org @ internet, Harry Lewis/Boulder/IBM at ibmus
cc:
Subject: Re: IPP> Re: JMP> Cancel
Hi Harry,
What I'm concerned about is that when the job remains in PROCESSING
with 'processing to StopPoint', there is no way to tell (by state or state
reasons) that the operation-in-progress was CANCEL versus ABORT
versus (if the Job Mon MIB supported it) the DPA Job Interrupt
(checkpoint the current job and then start this different one).
If you are doing a checkpoint (for Job Interrupt or Job Hold
operations), then 'processingToStopPoint' is a normal, healthy
state reason. If the the job was 'cancelledByUser' or
'cancelledByOperator'or aborted by the system, then the
only indication in the state reasons (until the exception
operation COMPLETES) is 'processingToStopPoint' (in your
latest, where the 'cancelledBy...' reason isn't set until the Cancel
completes).
Cheers,
- Ira
----------------------------------------------- Harry'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 AA05411; Tue, 2 Sep 97 00:26:08 EDT Received: from
alpha.xerox.com by zombi (4.1/SMI-4.1) id AA03220; Tue, 2 Sep 97 00:21:46
EDT
Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com
with
SMTP id <52913(3)>; Mon, 1 Sep 1997 21:22:26 PDT Received: from localhost
(daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id
AAA00385
for <imcdonal at eso.mc.xerox.com>; Tue, 2 Sep 1997 00:18:39 -0400 (EDT)
Received:
by pwg.org (bulk_mailer v1.5); Tue, 2 Sep 1997 00:17:04 -0400 Received:
(from
daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id AAA00244 for
jmp-outgoing; Tue, 2 Sep 1997 00:16:20 -0400 (EDT) From: Harry Lewis
<harryl at us.ibm.com> To: <jmp at pwg.org> Subject: IPP> Re: JMP> Cancel
Message-Id:
<5030300009721184000002L042*@MHS> Date: Mon, 1 Sep 1997 21:21:15 PDT
Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner at pwg.org Status:
R
Hi, Ira. Thanks for chiming in on this.
You asked if there was any state that indicated "jobCancelInProgress" or
"jobAbortInProgress" and I guess that's what I am suggesting
"processingToStopPoint" can represent. There are other reasons to be
processing
to stop point like someone hitting a runout button on systems with a large
pipeline of data in the printer. But, in general, we have chosen
"processingToStopPoint" as an indication that, for some reason, the job is
soon
to STOP, i.e. has been canceled. We prefer "canceledByUser" or "ByOperator"
as
reasons for the CANCEL state, not the PROCESSING state, but I don't think
there
would be any harm including them in both places... would there, Tom? In
fact, I
don't think there is harm in mixing reasons with
states in any combination that appears useful... but we were trying to
establish a higher degree of interoperability.
I never really liked "job state reasons" in the first place, and I think
this
leading, trailing edge discussion demonstrated why. You can't built a state
driven system. If we just had a fairly simple set of states (like we do)
with
the addition of a state like "canceling", then the end-user, wanting the
leading edge feedback would care about this state and the accounting app
wanting final state data would care about "canceled".
Your point about the Cancel failing landed a bit over my head and in the
corner
somewhere. I *think* maybe I should be worried about this (now that you
mention
it) but I'm not really convinced. If a cancel fails, I'm not sure the
leading/trailing edge discussion applies. That's only a matter of do you
find
out in 4 seconds or 16 seconds (3 more sheets in the path to flush).
For interoperability sake, I continue to encourage the use of
PROCESSING - processingToStopPoint
CANCELED - canceledByUser(Operator).
Harry Lewis - IBM Printing Systems
------ Forwarded by Harry Lewis/Boulder/IBM on 09/01/97 10:00 PM -------
ipp-owner at pwg.org on 08/31/97 06:21:59 PM
Please respond to ipp-owner at pwg.org @ internet
To: hastings at cp10.es.xerox.com @ internet, Harry Lewis/Boulder/IBM at ibmus
cc: jmp at pwg.org @ internet, ipp at pwg.org @ internet
Subject: IPP> Re: JMP> Cancel
Hi Harry and Tom,
I agree that 'processingToStopPoint' seems to make more sense in the
PROCESSING state. But there aren't any state reasons names
'jobCancelInProgress', 'jobAbortInProgress', etc, to tell you
what's going on (would we still use 'cancelledByUser' BEFORE finishing
the Cancel and going to the CANCELLED terminal state?). Although
the Cancel takes finite time, I'm inclined to make the state show the
LEADING edge of the Cancel transaction and not the TRAILING edge,
so that job state-based monitoring gets a 'wakeup' to go look at
job state reasons.
Harry, thank you for mentioning the dreaded job events/traps.
I agree that robust accounting should take advantage of such
job events/traps, when available. But I'd like the LEADING
edge state change to encourage ALL accounting applications to
do what we want - take a new snapshot of the job's counters,
in case the Cancel (or Abort) FAILS during processing.
Cheers,
- Ira McDonald (outside consultant at Xerox)
High North Inc
PO Box 221
Grand Marais, MI 49839
906-494-2434
------------------------- Harry's note ----------------------------------
>From jmp-owner at pwg.org Sat Aug 30 12:10:15 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 AA05187; Sat, 30 Aug 97 12:10:14 EDT Received:
from
alpha.xerox.com by zombi (4.1/SMI-4.1) id AA25983; Sat, 30 Aug 97 12:05:57
EDT
Received: from lists.underscore.com ([199.125.85.31]) by alpha.xerox.com
with
SMTP id <53329(4)>; Sat, 30 Aug 1997 09:06:36 PDT Received: from localhost
(daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id
MAA26109
for <imcdonal at eso.mc.xerox.com>; Sat, 30 Aug 1997 12:02:45 -0400 (EDT)
Received:
by pwg.org (bulk_mailer v1.5); Sat, 30 Aug 1997 11:59:49 -0400 Received:
(from
daemon at localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA25994 for
jmp-outgoing; Sat, 30 Aug 1997 11:58:31 -0400 (EDT) From: Harry Lewis
<harryl at us.ibm.com> To: <hastings at cp10.es.xerox.com> Cc: <ipp at pwg.org>,
<jmp at pwg.org> Subject: Re: JMP> Cancel Message-Id:
<5030300009649734000002L042*@MHS> Date: Sat, 30 Aug 1997 09:02:05 PDT
Mime-Version: 1.0 Content-Type: text/plain Sender: jmp-owner at pwg.org Status:
R
Tom, thanks for sharing your observations about whether the CANCEL state
should
be entered upon request or upon completion of the CANCEL. I have two
comments.
You said it would be an error in IPP is CANCEL were received more than once
for
the same job. I agree that changing state upon request gives more timely end
user feedback. But, there are inevitable always going to be system latency
in
any request... changing state upon completion just adds more. So I think IPP
must have a way to handle multiple CANCEL commands anyway.
You also gave a good explanation of a robust polling based accounting
application which is basically continuously harvesting and sifting. I agree,
with this type of implementation, my argument about deterministic accounting
is
less valid.
However, this is not the only type of robust accounting system that can be
designed around the job MIB. If ever there were an event driven system or
SENSE
type of involvement, I still feel it would be better for the CANCEL state to
really mean CANCEL complete. I'm sure I've opened myself to criticism, here,
in
that the Job MIB is currently not event savvy. But, there is no reason it
couldn't be (other than we didn't want to tackle the problem) and I am
indicating, if we ever moved in that direction, a deterministic set of
states
is preferable.
I do feel bad about the editing, Tom. I admit, at Redmond we (I) mainly
discussed processingToStoppedState as a reason to be associated with CANCEL
not
PROCESSING. This is way I suggested an "interoperability FAQ"... so as not
to
require more work on the current draft. But, if you have already tied in
verbiage that strongly indicates the opposite, we'd have a problem, wouldn't
we.
I will certainly volunteer to perform the editing task if we resolve that
CANCEL state means cancel complete!
Harry Lewis - IBM Printing Systems
---------- Forwarded by Harry Lewis/Boulder/IBM on 08/30/97 09:42 AM
-------------
hastings at cp10.es.xerox.com on 08/29/97 08:54:36 PM
Please respond to hastings at cp10.es.xerox.com @ internet
To: Harry Lewis/Boulder/IBM at ibmus
cc: jmp at pwg.org @ internet
Subject: Re: JMP> Cancel
Harry,
A good debate. However, I hope that we can reach agreement on one or the
other and put it into the specification itself. The FAQ should only be
for things that come up after we've closed the specification. (I don't
want to delay closing the spec either, because no matter how long we
wait, there will always be some questions or issues like this that
come up).
I tried hard to write up the JMP and IPP specs so that your plan B was the
only
interpretation. If we agree that plan A is the desired plan (or that
either A or B can be done depending on implementation), then I want
to clarify both the IPP and JMP specs.
See my comments below.
Tom
At 12:45 08/29/97 PDT, Harry Lewis wrote:
>We've had a bit of debate, here, about whether, upon detecting a cancel
>request, the agent should
>>A. STATE=Processing REASON=processing to stop point
>>B. STATE=Cancel REASON=processing to stop point
>>We were dealing with plan B when we requested processingToStoppedPoint
moved
>into Reasons-1. Our current debate does not effect that change, or require
any
>new adjustments to the job MIB. We are more convinced, now that
>plan A is better and I only offer this as an interoperability issue.
I agree that having two ways might create an interoperability issue.
>>The crux of the discussion is whether it's better to change State to Cancel
>ASAP upon recognizing the request (B) or
>not change State to CANCEL until the cancel operation is complete and all
MIB
>values are in their final state. Earlier, we thought it necessary to
reflect
>the Cancel REQUEST for timely user feedback but now we think it better to
favor
>deterministic behavior from an accounting point of view. Being remote, the
user
>probably won't be effected by the "lag" - and if an application really
wants
>to, it can sense, from the reason, that a cancel must be in process.
>From an IPP point of view, it is very important that the job change state
on receipt of the CancelJob operation. A subsequent CancelJob operation
becomes an error if the job is already in the canceled state. But if the
job can linger in the processing state, then multiple cancels could be
done. Or the user seeing the state as still processing, might be inclined
to issue the cancelJob again (like pushing the crosswalk buttom several
times).
But lets get down to the real debate point (thanks for including your
reasons why the change): about the accounting being deterministic.
We have discussed this point at Xerox too and we feel that a robust
accounting program must be polling all the time and writing out about jobs
onto some sort of safe storage on each poll. Then if the system, or the
accounting program, or the device crash, or the acounting program doesn't
get back on its next poll cycle in time before the job is deleted,
there is still accounting information written (even if incomplete). If an
accounting program refrains from writing anything about a
job, until the job reaches one of the three terminal states (completed,
aborted, canceled), then the accounting program might miss accounting
information if any of the 4 contingencies happen. Thus we don't think
that we should change the job state model definition (of processing to
keep the job in processing until the stop point is reached) to "help"
accounting, since the accounting should be written in a more robust manner
anyway.
Thus it doesn't matter whether the accounting program knows whether
all of the data is finished changing or not (by seeing that the job has
achieved one of the 3 terminal states). The accounting program might want
to avoid re-writing a job's accounting record, if the data is all the same,
but that can be done by filtering.
In fact, each of the three terminal states, might have additional processing
after immediate transition to them.
Comments?
Thanks,
Tom
>>I'm open to comments.
>>I'd like to reach agreement and include a FAQ entry stating that, since
CANCEL
>is a *completion* state, the transition should not take place until CANCEL
is
>complete.
Again, I'd like to resolve before close of the document and put it in
the document, if we can.
>>Harry Lewis - IBM Printing Systems
>>