Subject: JMP> Cancel

From: Harry Lewis <[email-masked]>
Date: Fri, 29 Aug 1997 15:45:28 -0400

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.

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.

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.

Harry Lewis - IBM Printing Systems

---

From: Ron Bergman <[email-masked]>
Date: Fri, 29 Aug 1997 16:39:45 -0700 (Pacific Daylight Time)

Harry,

This was my original position when this issue was first discussed.  I
backed down when it was desired to only use jmJobState to indicate to
the user that the job was indeed cancelled.

I certainly support your change in position.

	...Ron