Ira, I'm glad we seem to be reaching agreement.
If you'll look on pg60, line 2357 of the v0.85 Job MIB, you'll find we already
have the abortedBySystem reason you wished for ;-). It's even part of
reasons-1... so that's good news.
We feel it is sufficient to transition directly from PROCESSING - jobPrinting
to ABORTED - abortedBySystem, however. This is a different situation than
CANCEL, were someone has initiated a process and may be looking for leading
edge feedback prior to completion of that process. With an abort by the
printer, itself, even if the system recognizes the leading edge of the abort
(i.e. maybe an I/O time-out?), then has to flush 3 pages (ex). to complete the
abort, I'm not sure the value of showing PROCESSING - abortedBySystem as
opposed to simply ABORTED - abortedBySystem.
I would not strongly object to this useage... from an interoprability point of
view, however, I wouldn't recommend it unless further convinced.
Harry Lewis - IBM Printing Systems
---- Forwarded by Harry Lewis 09/04/97 08:43 AM ----
jmp-owner at pwg.org on 09/03/97 09:44:09 PM
Please respond to jmp-owner at pwg.org @ internet
To: imcdonal at eso.mc.xerox.com @ internet, Harry Lewis/Boulder/IBM at ibmus
cc: jmp at pwg.org @ internet
Subject: Re: IPP> Re: JMP> Cancel
Hi Harry,
I agree entirely with your model for the states and state reasons
(ie, show the leading edge of an operation via state reasons and
the trailing edge via states).
I wonder if we don't need an 'abortedBySystem' state reason, though.
Even if the "cancel" was by the system (as an ABORT), could a
job be 'processingToStopPoint' for awhile in one of your printers?
I never liked making the transition to 'Cancelled' before th
operation was actually completed. It doesn't feel right for
resilience.
Cheers,
- Ira McDonald
906-494-2434
----------------------------- Harry's note -----------------------------
Return-Path: <harryl at us.ibm.com>
Received: from zombi (zombi.eso.mc.xerox.com) by snorkel.eso.mc.xerox.com
(4.1/XeroxClient-1.1) id AA06048; Wed, 3 Sep 97 12:00:39 EDT Received: from
alpha.xerox.com by zombi (4.1/SMI-4.1) id AA12980; Wed, 3 Sep 97 11:56:14 EDT
Received: from lms03.us1.ibm.com ([198.133.22.39]) by alpha.xerox.com with SMTP
id <53385(3)>; Wed, 3 Sep 1997 08:56:55 PDT Received: from
d03lms03.boulder.ibm.com by lms03.us1.ibm.com (AIX 4.1/UCB 5.64/4.03)
id AA16984; Wed, 3 Sep 1997 14:47:37 GMT
Received: by US1.IBM.COM (Soft-Switch LMS 2.0) with snapi via D03AU032
id 5030300009845956; Wed, 3 Sep 1997 12:00:08 -0400
From: Harry Lewis <harryl at us.ibm.com>
To: <imcdonal at eso.mc.xerox.com>
Cc: <jmp at pwg.org>
Subject: Re: IPP> Re: JMP> Cancel
Message-Id: <5030300009845956000002L062*@MHS>
Date: Wed, 3 Sep 1997 09:00:08 PDT
Mime-Version: 1.0
Content-Type: text/plain
Status: R
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 -------------------
>From jmp-owner at pwg.org Tue Sep 2 00:26:09 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 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
>>