Agreed.
At 15:35 04/30/97 PDT, Harry Lewis wrote:
>Classification:
>>Whether we have a state table or not, the reasoning behind jmJobStateValue is
>to reduce polling. Without jmJobStateValue, which is a DEFINITION of which
>attribute is most "important" to a MONITORING application given a particular
>state, there are two alternatives, neither of which is as effective, and
>results in more network traffic.
Agreed.
And the state is even required by an ACCOUNTING application,
so the jmJobStateValue is replicated in the Attribute Table as
jobState(3) attribute, so that an accounting application can skip over
jobs that are not yet completed.
>> 1. Poll twice, once to determine the state and then to get the more meaningful
>value
>> 2. Poll for all the (potentially meaningful) objects.
I wonder if it would help the discussion to specify exactly what an application
specifies in a Get or GetNext for 1 and 2 with both the Job State Table
and the Attribute table versus with only the Attribute Table.
I suspect that even a minimal monitoring application has to get to the
Attribute table at least once for each STATIC attribute, such as
jobOwner(15), and maybe documentName(27).
>>Harry Lewis - IBM Printing Systems
>>