So JMP coul have a held state, instead of the jobHeld generic state
reason. One of the reasons that IPP merged the held job state into
the pending job state, is the difficulty of doint state diagrams where
there is a branch into two states, depending on the situation, such as
a job going into held or pending depending on its attributes and the
configuration of the printer.
However a JMP agent isn't implementing the state machine, its only reflecting
what the underlying printer implementation is doing. So the comlication
of having two state: held and pending is a problem for the agent. The
agent just represents to the application through the MIB, the underlying
state of the implementation. So the agents doesn't have the problem of
implementing the more complicated state machine with both a held and a
pending state.
For those of you into object modeling, the Shlaer-Mellor school only
allows a decision when exiting a state, not when entering. So with
Shlaer-Mellor implementation you have to introduce a temporary intermediate
evaluating-hold state in which the exit from the state is whether the job
goes into the held state or into the pending state. But with using
job-state-reasons, instead, all this complication goes away, because the
job is always in the pendin state. Its the job state reasons that prevent
the implementation from choosing a job that can't be processed.
At 08:29 05/27/97 PDT, Ron Bergman wrote:
>
>
>On Sun, 25 May 1997, Tom Hastings wrote:
>
>> 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.
>>
>RB> I would vote for number two if these were are only choices.
Alternative 2 is fine with me too, if we relax our zeal of trying to
convince IPP to change. Can we agree to just make sure that it is easy
for a JMP agent to map IPP to the MIB?
Can you think of other alternatives?
>>
>> >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".
>>
>RB> I don't see any difference in "required" vs "requested".
You are right. You can't put everything into the spec.
Does the following description help for the condition which has been
further rename by IPP to: job-hold-until-resources-are-ready
which in the MIB is jobHoldUntilResourcesAreReady:
At least one of the resources needed by the job, such as media, fonts,
resource objects, etc., is not ready on any of the physical devices for
which the job is a candidate.
Usually such a condition is detected while the job is in the pending state.
If a job starts processing and encounters a resource that is not ready,
there are two possible implementations:
(1) the device is stopped and no jobs can run until the resource(s) are made
ready, in which case the agent shall keep the job in the processing state
and shall add the deviceStopped reason to the job's jmJobStateReasons1 object
OR
(2) another job is found to use the device while the current job goes back
to waiting for its turn and for the resources to be made ready, in which
case the Printer shall change the job's jmJobState object to pending and add
the jobHoldUntilResourcesAreReady value to the job's jmJobStateReasons1
object. Job states: pending, jobHeld shall be set.
>
>> 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.
>>
>RB> Have we eliminated too much?
Maybe. But the jobHold generic state reason in JMP (not in IPP) is another
way to represent the held state, but using the reason mechanism.
It depends on whether it is more important for JMP to have the same
state as IPP and JMP only have additional job state reasons, or whether
JMP can also have additional job states that cleanly sub-divide an IPP
job state. E.g., the IPP pending state maps to either the JMP held state
or the JMP pending state, depending on the job state reasons that do or don't
prevent the job from being a candidate for processing.
>
>> 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.
>>
>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.
Makes sense to me also for IPP 'pending' to map to JMP held vs. pending.
How can we get a "vote" on this?
However, for needsAttention, we still haven't discussed the IPP point that
as far as the user is concerned his/her pending job that is pending for a
stopped printer is just as much affected as when his/her processing job is
the current job that is using the printer when the printer stopped.
Neither the pending job nor the processing job will finish until the
printer attended to so that the printer is no longer stopped.
>
>> >(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?
>>
>RB> I did not intend this to be a major issue. Leave it in.
Done.
>
>> >
>> >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.
>>
>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.
But what about the pending jobs? They are just as much affected by the
printer needing attention as the job in the processing state. The jobs
in the pending state won't get done until the printer is attended
to either.
>
>> 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.
>>
>RB> Again, I would support keeping both the needsAttention and held
>RB> states. These could easily be mapped to IPP. Comments?
Adding a JMP held state that is not in IPP is fine. The mapping from IPP
to JMP done by the JMP agent is that any IPP job-state-reasons value keyword
that starts with 'job-held-' would cause the agent to display the job in the
held state, instead of the pending state. If there were no 'job-held-xxx'
reason, then the IPP 'pending' state maps to the JMP pending state. As soon
as all of the 'job-held-xxx' IPP reasons are gone, the agent would display
the job in the pending state, instead of the held state. Again, the agent
need not make the state change until an application makes a query of that
job and then the agent performs a "lazy evaluation" of the job state by
looking at the current IPP job-state-reasons attribute values.
For mapping the IPP printerStopped job-state-reason, if JMP wants only
the processing jobs have have a problem to be in the JMP needsAttention
state, then the agent maps as follows:
IPP state IPP job-state-reasons JMP state JMP jmJobStateReasons1
--------- --------------------- --------- ----------------------
pending printer-stopped pending -
pending job-held-until-specified held jobHeldUntilSpecified
processing printer-stopped needsAttention -
processing job-printing processing jobPrinting
Several tweaks to the above mapping table are:
1. Change the first "-" above to: deviceStopped. Then all the pending jobs
get to see that they are waiting for a printer that is stopped.
2. Change the second "-" above to deviceStopped which would be redundant
with the needsAttention state, but does preserve the job state reasons
compatibility between JMP and IPP for this reason.
>
>
> Ron Bergman
> Dataproducts Corp
>
>
>