Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 6. when job state reasons must be turned on and off

From: Tom Hastings <[email-masked]>
Date: Fri, 29 Aug 1997 15:44:42 PDT

At 18:46 08/28/97 PDT, Ron Bergman wrote:
>Tom, 
>
>I understand exactly what you you mean.  That is not the issue.
>
>What I was trying to say in my new wording is that the Job Monitor Ap
>should read the Job State Reasons every time he attempted to update (i.e.
>read) the job state.  He may read the job state many times before it 
>changes.  My meaning of "update" was "the monitor reads the job state".
>
>So let me reword again:
>
>  "Since the Job State Reasons will be more dynamic than the Job State,
>   it is recommended that a job monitoring application read this object
>   every time jmJobState is read."
>
>Is this better?

Much better!  I can live with it.

>
>	...Ron
>
>
>
>On Thu, 28 Aug 1997, Tom Hastings wrote:
>
>> Ron,
>> 
>> Lets keep the discussion going on job state reasons, because your proposed
>> workding is just what I am worried about.  My understanding of your proposed
>> wording suggests that the agent only need make the reasons be correct,
>> when the job state changes.  This is exactly the interpretation that
>> the participant asked if it was ok to only make the reason be correct
>> when the job changed state (and was like the old PDP-11 devices).
>> 
>> In fact, an application is encouraged to look at the reasons whenever
>> it looks at the job.  Also since we don't have trapping, there is no
>> way for an application to know when a job actually changes state, except
>> to notice that the job state value is different on the current poll cycle
>> from the last poll cycle.
>> 
>> I want to make it clear that the job state reason value(s) may:
>> 
>>   1. change when the job state changes (the usual case)
>> 
>>      Example: job changes state from 'processing' to 'completed' and the 
>>      'jobCompletedSuccessfully' reason is set at the same time.  This reason
>>      remains set for the entire remaining life of the job in the 'completed'
>>      state.
>> 
>>   2. change while the job state does not change, i.e., some job state
>>      reasons may come and go while a job remains in the same state
>>      (less likely)
>> 
>>      Example: the job is in the 'pending' state and the printer stops,
>>      so the reason 'deviceStopped' comes and goes while the job remains
>>      in the 'pending' state.
>> 
>>      Example: the job is canceled so the job transitions from 'processing'
>>      to 'canceled', with the (new) 'processingToStopPoint' reason is set
>>      and the 'jobPrinting' reason may be set.  
>>      However, while the job is in the 'canceled' state, the processing to
>>      stop point completes and the marking media completes, so that the 
>>      'processingToStopPoint' and the 'jobPrinting' reasons go away (and
>>      not necessarily at the same time).
>> 
>>   3. remain the same while a job changes state (rare, but possible).
>> 
>>      Example: a job with the "jobHold" attribute set would have the 
>>      'jobHoldSpecified' reason set as well.  However, if the job was
>>      canceled, the job would change from the 'pendingHeld' state to the
>>      'canceled' state.  The implementation MAY keep the
>>      'jobHoldSpecified' reason set during the remaining life of the job.
>>      
>>      
>> I'm also trying to understand your concerns about the wording below:
>> 
>> At 15:37 08/27/97 PDT, Ron Bergman wrote:
>> >Tom,
>> >
>> >I still do not like the disputed text and do not believe that it properly
>> >answers the question.  I propose as an alternative:
>> >
>> >  "Since the Job State Reasons will be more dynamic than the Job State,
>> >   it is recommended that a job monitoring application read this object
>> >   every time the current Job State is updated."
>> >
>> >This presents the same idea from a different perspective and also
>> >eliminates the tone of the previous statement that "this object is
>> >special and must be valid".  And also implies that other objects do
>> >not have to be valid since I did not explicitly say so.
>> 
>> I'm still puzzled as to why you think the phrase: "when implemented as 
>> with any MIB data" makes the reasons be special.  The statement is trying
>> to say that reasson, like any other MIB data, must agree with the conditions
>> of the device.  
>> 
>RB--  My point is, we write a specification which defines the meaning
>RB--  for an object.  We should not then have to then say, "if you
>RB--  implement this object, it must be valid".
>
>> I'm also puzzled as to why you think that the same phrase: "when implemented
>> as with any MIB data" allows any other MIB data to not be valid?
>> 
>RB--  By making a special case here it could be implied.  If this is true
>RB--  for all other MIB data, why does have to be stated explicity here?
>
>> Is there a better way to say that reasons must be just as valid as
>> other MIB objects and attributes and that reasons must not become stale
>> (as with any other MIB data)?
>
>RB--  Good implementations always present valid information and should 
>RB--  not have to be explicity told.  I am trying to answer the question
>RB--  in, what I believe, is a better point of view.  By indicating that
>RB--  the Monitoring Ap must look at this often implies what you have
>RB--  been trying to say.  Again, I do not disagree with your statement,
>RB--  I just do not feel it belongs in the document.
>> 
>> Tom
>> 
>> >
>> >Again, this is a minor issue and I am being somewhat hard-nosed, but
>> >I would like to get the wording correct now.
>> >
>> >
>> >	...Ron
>> >
>> >
>> >On Tue, 26 Aug 1997, Tom Hastings wrote:
>> >
>> >> At 16:59 08/20/97 PDT, Ron Bergman wrote:
>> >> snip...
>> >> 
>> >> >> >6. In jmJobStateReasons1 (page #81), I find the following statement
>> >> >> >   hard to disagree with, but why do we need to state this?
>> >> >> >
>> >> >> >       "Furthermore, when implemented as with any MIB data, the
>> >> >> >        agent SHALL return these values when the reason applies and
>> >> >> >        SHALL NOT return them when the reason no longer applies
whether
>> >> >> >        the value of the job's jmJobState object changed or not."
>> >> >> >
>> >> >> >    All this really states is that the value of an object must be
valid.
>> >> >> >    We do not have a similar statement for any other object.
>> >> >> 
>> >> >> I disagree.  One commentor asked whether the bits had to be turned
off or
>> >> not,
>> >> >> so I felt it was important to clarify that these bits are
meaningful while
>> >> >> the job is in each job state, not just when the job transitions
from one
>> >> >> state to another.  There are hardware implementations in which such
bits
>> >> >> are only meaningful on the state transitions.  As far as I'm concerned,
>> >> >> if someone asks about something it can't hurt to include the
explanation
>> >> >> in the document.  There will be others who will ask the same
question, but
>> >> >> we won't be there to answer.
>> >> >> 
>> >> >Since the question was asked, this should be in the FAQ and not in the
>> >> >specification.  All this sentence states is "thou shall not lie".  If
>> >> >the document states that this attribute indicates this condition and
>> >> >the implementation sets the attribute when the condition is not true,
>> >> >the implementation is violating the specification!  I do not believe
>> >> >that the document should answer every question that was asked.  That
>> >> >is why we should have a FAQ.
>> >> 
>> >> The question was asked about the text that was in the spec.  I believe
>> >> that the FAQ should be answering questions that people have how haven't
>> >> read the document or are getting into it.  Of course, after we publish
>> >> the specification, we can also use the FAQ to answer questions of
>> interpretation
>> >> of the standard, which would be better than nothing (since we can no
longer
>> >> update the spec).
>> >> 
>> >> So if we have a question about interpretation of the text in the spec
>> >> BEFORE the spec is published, the answer should go in the spec. 
>> >> 
>> >> Also from my experience with hardware devices, such as PDP-11 I/O
>> devices, the
>> >> question was whether the bits where only to be sampled when a job state
>> >> transition occurred, such as in some I/O devices, or could be sampled any
>> time.
>> >> 
>> >> Finally, I took into account your concern/question about "why wouldn't we
>> >> have to make a similar statement about other objects in the MIB", by
adding
>> >> the phrase: "as with any MIB data", so we don't have to add the phrase
>> >> to any other object.
>> >> 
>> >> Since you said it was hard to disagree with, lets leave it in.  Ok?
>> >> 
>> >> Tom
>> >> 
>> >> 
>> >> 
>> >
>> >
>> >
>> 
>> 
>
>
>

---

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

Great!  This closes the last of my issues.  The text from my 8/28/97
email will replace the existing text from issue 6.

The existing text:

I hope everyone has a good weeked!  I certainly will!

	...Ron