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