In IPP, the Printer's printer-state would have the value: 'stopped'
the Printer's printer-state-reasons would have the value: 'paused'
(or maybe 'shutdown', depending on how the queue was stopped by the
operator).
all the 'pending' jobs would have the job-state-reasons value:
'printerStopped'
all the 'processing' jobs would have the job-state-reasons value:
'printerStopped'
In JMP, the jobStateReasons2 attribute would have the serviceOffLine
reason set (bit 0x400000) for all jobs in the pending state.
Same for the JMP held state, if JMP has such a state.
But JMP doesn't have a Printer, except the Printer MIB, so there isn't
the same good stuff about the Printer that IPP has.
>
>> 2. If a queue is stopped, how can the user easily detect this
>> critical queue-specific state?
In IPP, the user gets back some Printer status when querying the job
as well as job state.
In JMP, its harder, since JMP only has the deviceAlert attribute which
is the hardware alert code from the Printer MIB. No much about queues
in the Printer MIB.
We could add two objects to the JMP jmGeneralTable that mirror these two
IPP Printer attributes:
jmGeneralState
jmGeneralStateReasons
which indicate the state of the job set and the job set state reasons.
The values from IPP printer-state and printer-state-reasons would be:
jmGeneralState: unknown, idle, processing, stopped
jmGeneralStateReasons: stopped-partly, stopped, media-needed, paper-jam,
paused, shudown, connect-to-printer, timed-out, stopping
Should we?
>
>> 3. Similarly, if a queue is disabled, how can the user detect
>> this state?
In IPP, the Printer has the boolean Mandaory attribute:
printer-is-accepting-jobs
Again, we don't have the equivalent in the JMP MIB. We could add a
boolean object to the jmGeneralTable: jmGeneralIsAcceptingJobs
to give the same information on a Job Set basis.
Should we?
>
>There is an analogous situation for the state NeedsAttention. One could
>ask, if the printer has an alert, should all the jobs in the printer buffer
>change to NeedsAttention state, or just the job which is currently printing.
IPP has been stating that the end user wants to know the bad news for
his/her pending job, not just for his/her processing job.
>Our recommendation is not to ripple all jobs since this would be arduous for
>the agent.
I agree that rippling would be arduous for the agent, so don't ripple.
May I suggest that there is no ardor at all, if the agent just waits until
the job is queried to return the jmJobStateReason1 value is deviceStopped,
if the device is still stopped. If the device got going again before the
'pending' job was queried, then no extra work was done by the agent for
that job. So there need be no "rippling at all".
> Rather, we envision the job monitoring application also having
>some indication of the overall health of the printer (Green, Yellow, Red).
>Only the job which is actually JAMMED (as an example) would reflect
>NeedsAttention state. Other jobs would be Pending on a "Red" printer.
But the IPP 'printer-stopped' value in the "job-state-reasons attribute"
is exactly the 'red' printer indication, but the indication comes more
conviently with the job in the job-state-reasons attribute. The IPP
printer-state is also stopped, if the user did query the Printer.
The big advantage to JMP of using the same approach of the deviceStopped
value of the jmJobStateReasons1 object, is that it works for all three
of our supported JMP configurations, not just configuration 1 (client talks
directly to the output device). So that the Printer MIB isn't needed in
order for the user to get the "red" printer indication back.
>I would really like JMP and/or IPP confirmation of this approach for printer
>implementations and I offer it in response to your question about queue's as
>an analogy, presuming you could show overall queue status with a (Green,
>Yellow, Red) icon.
>
>As for your last question:
>
>> 4. If a system administrator deletes a job from a queue, what should
>> the state and job reason(s) reflect?
>
>I am not in favor of job state reasons as anything other than optional job
>attributes, but if I were to take a guess, here, I'd say that:
>State = CANCELED
>JobStateReasons1 = No reason (all zero's)
Current and previsou spec has canceledByOperator or canceledByUser as values.
Remember Jay's mail that the user needs to be able to tell whether the user,
the operator or the system canceled his/her job. Now that IPP/JMP have
the aborted state, the system canceled jobs is indicated by the 'aborted' job
state, so that reason has gone away.
He also wanted it to be mandatory, so I moved jobStateReason1 attribute to the
jmJobTable and called it jmJobStateReason1.
>JobStateRessons2 = deletedByAdministrator
That is in jmJobStateReasons1
>JobStateReasons3 = No reason
>JobStateReasons4 = No reason
>
>So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000?
More like: 0x00002000 0x00000000 0x00000000 0x00000000
with job-state spec I just posted.
>
>Harry Lewis.
>
>