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: Tue, 26 Aug 1997 17:48:01 PDT

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: JK Martin <[email-masked]>
Date: Thu, 28 Aug 1997 08:12:10 -0400 (EDT)

I agree with Ron.

	...jay

----- Begin Included Message -----

>From [email-masked] Wed Aug 27 18:37 EDT 1997
Date: Wed, 27 Aug 1997 15:37:57 -0700 (Pacific Daylight Time)
From: Ron Bergman <[email-masked]>
To: Tom Hastings <[email-masked]>
cc: [email-masked]
Subject: Re: JMP> Open Editorial Changes From Rev. 0.83: 6. when job
  state reasons must be turned on and off
X-X-Sender: [email-masked]

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.

Again, this is a minor issue and I am being somewhat hard-nosed, but
I would like to get the wording correct now.

	...Ron

----- End Included Message -----