Subject: Re: JMP> jmJobState and jmJobStateReasonsTC [ISSUE: Are there any mandatory job states?]

From: Tom Hastings <[email-masked]>
Date: Sun, 25 May 1997 02:42:36 PDT

The current draft lists processing, needsAttention, canceled, and completed
as Mandatory.  Since needsAttention has gone away, that leaves three
states as mandatory:  processing, canceled, and completed.  Since we added
aborted, I assume that aborted should be added to the mandatory list.

The complicance at the end of the Job MIB spec also lists these states.

I assume that you didn't intend to remove that agreement.
So I'd like to add back the description that some are mandatory and the
rest are conditionally mandatory.  

I agree on removing redundant text.  However, in this case, the
description in jmJobState was simply a pointer to the textual
convention (after deleteing the sentence: "The value of this object shall
always be the same as that of the jobState attribute, so that this information
appears in both the jmJobStateTable and the jmAttributeTable simultaneously".
since we agreed to get rid of duplicates.

So the real thrust of your comment was to move the description from
the textual convention to the object.  So I'll add the sentence about
the mandatory states to the jmJobState object as well, ok?

Tom

At 10:01 05/23/97 PDT, Ron Bergman wrote:
>Tom, 
>
>In reviewing the Job MIB relative to the job states, I noticed that 
>the descriptions for jmJobState and JmJobStateTC are almost identical.
>I would like the specification for jmJobState to appear only once,
>and only in the jmJobState description.  I propose that these
>descriptions be revised as follows:
>
>jmJobState:
>-----------
>"The current state of the job (pending, processing, held, etc.). The 
>final value for this attribute shall be either completed or canceled. 
final value for this attribute shall be completed, canceled or aborted. 

>before the agent removes the job from the table.
>
>Management applications shall be prepared to receive all the standard 
>job states.  Servers and devices are not required to generate all job 
>states, only those which are appropriate for the particular 
>implementation.  The corresponding attributes JmJobStateReasons1 through
>JmJobStateReasons4 provide additional information about the job states.  
>While new job states cannot be added without impacting deployed clients, 
>it is the intent that additional Job State Reasons enums can be defined 
>without impacting deployed clients."
>
>JmJobStateTC:
>-------------
>"Defines the current state of the job."
>
>
>A similar situation exists for jobStateReasons1 and JmJobStateReasons1TC.
>Again, my recommendation is:

I'm assuming that we have agreed to make jobStateReasons1 mandatory, 
in order that the 'printer-stopped' value will always be present (the
new representation for the old needsAttention state that was removed).
Since jobStateReasons1 is an INTEGER, not OCTETS, we will move it to
the jmJobTable right after the jmJobState object, so that the descriptions
will be next to each other.  Its name will be jmJobStateReason1.

I've done some further shortening of the description that you proposed.
How does it look?

>jobStateReasons:
jmJobStateReasons1;
>----------------
>---OCTETS:  Additional information about the job's current state that 
Additional information about the job's current state that

>augments jmJobState.  The jobStateReasons1 attribute identifies the 
>reason or reasons that the job is in the held, pending, processing, 
>needsAttention, canceled, or completed state.  The agent shall indicate 
>the particular reason(s) by setting the value of the jobStateReasons1 
>attribute.  
augments jmJobState, including the reasons(s) that the job is in its
current state. 

<             When the job does not have any reasons for being in its 
>current state, the agent shall set the value of the jobStateReasons1 
>attribute to 0.
>
>Companion job state reasons Textual Conventions: JmJobStateReasons2TC, 
>JmJobStateReasons3TC, JmJobStateReasons4TC, are defined/reserved for an 
>additional 93 job state reasons for use with the corresponding 
>attributes: jobStateReasons2, jobStateReasons3, and jobStateReasons4.
Additional job state reasons may be represented by the attributes:
jobStateReasons2, jobStateReasons3, and jobStateReasons4.  See page xxx.
   
>This is a type 2 bit definition.
>
>JmJobStateReasons1TC:
>---------------------
>"This textual-convention is used with the jobStateReasons1 attribute to 
>provides additional information regarding jmJobState.
>
>The following standard values are defined (in hexadecimal) as powers of 
>two, since multiple values may be used at the same time:
>
>
>If anyone objects to these changes, please respond by June 13.
>
>
>	Ron Bergman
>	Dataproducts Corp.
>
>
>
>

---

From: Ron Bergman <[email-masked]>
Date: Tue, 27 May 1997 08:08:38 -0700 (PDT)

> aborted, I assume that aborted should be added to the mandatory list.
RB> As you know, there is still some discussion regarding needsAttention.

> rest are conditionally mandatory.  
RB> Exactly what does "mandatory" imply?  Is the state only reported
RB> if implemented?  It seems like it would be difficult to report if it
RB> is not implemented.   Then what is the difference between "mandatory"
RB> and "conditionally-mandatory"?  I propose that jmJobState is really
RB> what is "mandatory", not the possible values.  All values possible
RB> in an implementation must be supported.

> since we agreed to get rid of duplicates.
RB> In trying to answer your question I cannot find where I saw the
RB> duplicate text in jmJobState.  I may have been looking at jobState
RB> on page 35.  Will this (jobState) be removed in the next draft?

> the mandatory states to the jmJobState object as well, ok?
RB> That was not my original intent, but it is a good move.  See comment
RB> above regarding mandatory.

> will be next to each other.  Its name will be jmJobStateReason1.
RB> It appears that this may occur, but I don't believe that an agreement
RB> has been reached.  We still need to resolve the "needsAttention"
RB> issue.  Note that These issues should not delay the posting of the
RB> next draft update.
> augments jmJobState, including the reasons(s) that the job is in its
RB> Very good!

	Ron Bergman
	Dataproducts Corp.