You don't have to replicate jmJobState in the Attribute table since the State
table is defined to have greater persistence.
>> >Whoa, here. Replication of MIB values is an explicit non-goal of
>> >traditional MIB design, right? At least this is what Steve Waldbusser
>> >has repeatedly stated (and for good reason).
>> >
>> >If you're replicating values to somehow make it easier for a mgmt app,
>> >then I'd suggest the MIB is too complicated.
>>>> I agree completely that the same information should not have two ways to
>> be accessed. That is why I have been suggesting getting rid of
>> the Job State table altogether.
Further, Jay asked-
>This is what Harry explicitly does NOT want to do, right? (I'm asking
>just to make sure I've got these threads straight.)
Right, Jay. I do NOT want to get rid of the State Table. (I apologize,
the thread can get confusing).
>Tom, does removing the Job State Table result in the following:
> * Does not decrease the functionality needed to monitor job state,
> the number ONE reason for having the Job MIB in the first place
> * Makes the Job MIB less COMPLEX, and therefore easier to use by
> management apps and agents alike
It can be argued that moving ALL attributes (including State) to the
Attribute Table and removing the State Table will not reduce function. What it
will do is make it more difficult to monitor job progress (my opinion). Why?
Because the State Table is designed for easy index (via jmJobIndex) into a
row which contains the State and pertinent associated information. This
pertinent information changes per state. If state is pending, you don't need
to know which copy you are currently printing. If state is printing, you don't
need to know the number of intervening jobs.
If everything is lumped into the attribute table, you either have to determine
STATE and then go back for the pertinent information OR you need to grab a set
of POSSIBLE pertinent objects whenever you go for STATE and hope they all fit
in your varbind. Actually, there is a pretty good possibility that they will,
I believe. But, this is one of the problems the State table trys to address.
The only other reason I say an Attribute only solution would be functionally
equivalent but more difficult is due to the more complex indexing of the
attribute table. Attributes are indexed by JobSet, JobIndex, AttributeType,
and AttributeIndex (I may not have used the correct words here... another
dispute). The Job State Table is indexed by JobSet and JobIndex. If you are
using the "grab the state and 9 potentially meaningful values" method described
above, we think the response will be quite a bit slower due to the agent
handling all this indexing.
Slower response and complex indexing may be OK for the accounting application
(where we've always seen the greatest use for the attribute table), but
the job progress monitor may want quicker. Really, it may not even be a matter
of who can tolerate slow response as much as a matter of how many clients
or servers could be polling for job progress vs. the (fewer) number of
accounting apps putting the agent through it's paces on the attribute table.
>what can you tell us about Xerox's experience in prototyping this version
>of the standard Job Monitoring MIB?
Yes, I would like to hear anyone's response to the above in terms of their
prototype experience. I have been trying to share our findings rather openly.
Harry Lewis - IBM Printing Systems.