Subject: JMP> Job state implementation questions for Unix-based print

From: Harry Lewis <[email-masked]>
Date: Tue, 27 May 1997 12:29:43 -0400

Jay, these are good questions:

>Some questions:

>  1.  If a queue has been stopped, what should each job indicate for its
>      job state?

>  2.  If a queue is stopped, how can the user easily detect this
>      critical queue-specific state?

>  3.  Similarly, if a queue is disabled, how can the user detect
>      this state?

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.

Our recommendation is not to ripple all jobs since this would be arduous for
the agent. 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.

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)
JobStateRessons2 = deletedByAdministrator
JobStateReasons3 = No reason
JobStateReasons4 = No reason

So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000?

Harry Lewis.

---

From: Tom Hastings <[email-masked]>
Date: Wed, 28 May 1997 02:06:55 PDT

>>  1.  If a queue has been stopped, what should each job indicate for its

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.

>>      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

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?

>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.

>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

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.

>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

>So, I guess, that would look like 0x00000000 0x00000002 0x00000000 0x00000000?

More like:                         0x00002000 0x00000000 0x00000000 0x00000000 
with job-state spec I just posted.