Subject: RE: JMP> HELD vs NEEDS-ATTENTION

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

At 08:06 05/23/97 PDT, Ron Bergman wrote:
>
>I agree with all the changes proposed for alignment of the IPP and
>JMP job states except for the removal of "Needs Attention".  This
>should be the most important state to indicate to a user since 
>unless he takes action the job may never complete.  I would think
>that this would also be very important for IPP as well.

In IPP the job-state-reasons 'printer-stopped' is used instead of a separate
job state called 'needs-attention'.  The job can be in either the 'pending' 
or 'processing' state when the reason 'printer-stopped appears.
If the job is in the pending state, it is some other job that is having
the problem, but ALL pending jobs are affected, unless the printer problem is 
attended to.

We have two choices for the Job Monitoring MIB:

1. Follow IPP and get rid of the needsAttention state and add the
deviceStopped value to the JmJobStateReasons1TC.

2. Keep the needsAttention state.  Don't add the deviceStopped value to the
jmJobStateReasons1TC.  When an agent is instrumenting IPP,
the agent shall map the IPP 'processing' state to the JMP processing state, 
except when the IPP "job-state-reasons" contains 'printer-stopped'.  Then the 
JMP agent shows the job in the JMP needsAttention state.  When the IPP
'printer-stopped' value is removed from the IPP "printer-state-reasons" 
attribute, the JMP agent shall change the value of the job's jmJobState object
from the needsAttention state to the processing state.  The JMP
jmJobStateReasons1 object would remain unchanged during this.

>I also agree with Harry that "requiredResourcesNotReady" and
>"serviceOffLine" apply better to "Needs Attention" than "Held".

The IPP and JMP defintions of requiredResourcesNotReady, say "is not
ready on any of the physical devices for which the job is a candidate"
meaning before the job starts processing.  Perhaps this reason should
have a better name, like "requestedResourcesNotReady".

IPP says that when the reason 'printer-stopped' is present, the client
should check the printer-state and printer-state-reasons.  For JMP the
analoguous thing is to check the job's deviceAlert attributes and the
associated device MIB.

But the IPP/JMP meeting also got rid of the held state.

IPP also renamed 'required-resources-not-ready' to
'job-hold-until-resources-are-ready'.  The prefix "job-hold-" indicates
that the job is held and will not process until the reason goes away.

Again, JMP could still keep the held state, even though IPP doesn't have it.
Which may be a good idea, since MIBs use enums, not keywords, so that an
application can't tell from the enum code whether the job has to have the
reason removed before it can be processed, or whether the reason is a less
important one that doesn't affect whether the job will start processing or not.

Then a JMP agent would represent the IPP 'pending' state with certain
"job-state-reasons" value, such as 'job-hold-until-specified', and
'job-hold-until-required-resoureces-are-ready' as:

  the JMP 'held' state and also show the same jmJobStateReasons1 object values. 

>(I also agree with Harry that "Printing" is a better description
>for a user than "Processing".  Since this is an enum, a user or
>management ap can display whatever text that is deemed 
>appropriate.  So I will vote to keep "Processing" unless there
>is very strong support for "Printing".)
Thanks for being flexible.

>
>(Didn't we discuss "serviceOffLine" in a previous meeting and
>determined that no one except Dataproducts has ever implemented
>such a capability?  I also indicated that I had recently deleted
>the feature because I felt it was "stupid".)

I don't remember this.  Xerox has systems with service-off-line reason.
The jobs that have been previously accepted are indicated as being in the
held state with the serviceOffLine reason.  Clients can still query the
server since its the device that is really off-line, not the server.
Perhaps we should rename the reason from serviceOffLine, to deviceOffLine
and indicate that it is for configuration 2 in JMP?

>
>Also, I agree with Jay that "Needs Attention" should apply to all
>conditions, other than "Held", that prevents the job from printing.
>"Held" only implies an administratively set condition.

How can the Needs Attention job state apply to all conditions (states)?  
It could if Needs Attention were a job state reason.  In IPP we made Needs 
Attention a job state reason, but then renamed it to 'printer-stopped', 
because a device could need attention even though jobs were still
progressing, such as toner low.

So maybe you and Harry could support the IPP job-state-reason 'printer-stopped'
as equivalent a Needs Attention job state reason and more flexible than
if Needs Attention were a job state?

>
>Tom, since I could not participate in the Wednesday conference call,
>could you explain why "Needs Attention" was not accepted by IPP?
>It is very critical that JMP and IPP agree in this area and I would 
>hope this can be resolved quickly.

As I explained above, IPP thought that Needs Attention was better as a
job state reason, rather than a job state, and then we renamed the reason
to printer-stopped to be clearer.

I'm sorry that neither you nor Harry were able to call into the IPP
call last Wednesday.  The ball is in yours and Harry's court to see if
you like the IPP approach and we can use it directly in JMP or whether
JMP should perform a straight forward mapping when instrumenting an IPP
system as I outlined above to the JMP held and/or JMP needsAttention states
and some fiddling with job-state-reasons.

>	Ron Bergman
>	Dataproducts Corp

---

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

> jmJobStateReasons1 object would remain unchanged during this.
RB> I would vote for number two if these were are only choices.
> have a better name, like "requestedResourcesNotReady".
RB> I don't see any difference in "required" vs "requested".

> But the IPP/JMP meeting also got rid of the held state.
RB> Have we eliminated too much?

>   the JMP 'held' state and also show the same jmJobStateReasons1 object values. 
RB> I propose that we include the states that make sense for the Job MIB
RB> even if they are not in IPP, as long as they can be mapped into 
RB> currently defined IPP states and reasons.
 
> and indicate that it is for configuration 2 in JMP?
RB> I did not intend this to be a major issue.  Leave it in.

> progressing, such as toner low.
RB> Not States.. Conditions that prevent the job from printing, i.e. paper
RB> out, paper jam, out of toner, printer unplugged, etc, etc, etc.  Then
RB> the "needsAttention" state applies.

> and some fiddling with job-state-reasons.
RB> Again, I would support keeping both the needsAttention and held
RB> states. These could easily be mapped to IPP.  Comments?

	Ron Bergman
	Dataproducts Corp