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