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
On Fri, 29 Aug 1997, 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.
>
> 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
>