Agreed, as long as it doesn't open the MIB for re-design! But a top 25
list of uses, based on the current MIB, would be an excellent idea.
Harry Lewis - IBM Printing Systems
-------- Forwarded by Harry Lewis/Boulder/IBM on 07/08/97 08:46 PM ---------
jkm at underscore.com
07/08/97 05:56 PM
Please respond to jkm at underscore.com @ internet
To: Harry Lewis/Boulder/IBM at IBMUS
cc: jmp at pwg.org @ internet
Subject: Re: JMP> JMP FAQ?
You know what's needed here? None other than an equivalent of the
Printer MIB's "Top 25 Conditions" summary table.
That is, the JMP folks get together and devise the top-most set of
job-related scenarios, then determine the values for the relevant
Job MIB objects.
What say ye?
...jay
----- Begin Included Message -----
From: Harry Lewis <harryl at us.ibm.com>
To: <jmp at pwg.org>
Subject: JMP> JMP FAQ?
Date: Tue, 8 Jul 1997 16:38:19 -0400
The Job MIB is tending to be fairly "open" with respect to mandatory
attributes and jobStateReasons. We've struggled with how this may effect
interoperability.
Following is an example we've run into that illustrates the problem:
Consider a print job that gets canceled by the user (of course, with
our trusty camers - ONLY - we have no idea HOW the job got canceled;-).
Consider the two main applications monitoring via the Job MIB, 1) the
End User job monitor; and 2) the accounting application.
We feel the end user, in this situation, wants relatively instant feedback
that the job state has changed to CANCELED. But, cancel is a completion
state. We envision the accounting application waiting for jobs to be
complete then "harvesting" FINAL STATE attribute information.
Problem... there is some "intertia" in the print system. If the agent changes
state to CANCEL as soon as it becomes aware of the cancel command (to
satisfy the end user), there may still be a page or two in the pipeline
that the accounting application would miss if it noticed the state change
and performed it's data collection.
So, we suggest using jobStateReasons in this case.
CANCEL - processingToStopPoint
which progresses to
CANCEL - jobCanceledByUser
The question is, since these jobStateReasons are not "mandatory", how do we
communicate and agree on this recommendation? In other words, how do we
achieve interoperability?
I am suggesting a FAQ. I would like your comments on how effective you feel
this might be. If a FAQ is not effective, then, should be we deciding on more
mandatory attributes? I don't really want to pursue this path unless it is
absolutely necessary, because I feel we've been there... and it's UGLY!
>>> Harry Lewis <<<
----- End Included Message -----