Subject: Re: JMP> JobStateValue

From: Tom Hastings <[email-masked]>
Date: Thu, 8 May 1997 16:07:43 PDT

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

---

From: JK Martin <[email-masked]>
Date: Thu, 8 May 1997 19:29:47 -0400 (EDT)

Tom,

> jobs that are not yet completed.

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.

	...jay

---

From: Tom Hastings <[email-masked]>
Date: Thu, 8 May 1997 17:19:15 PDT

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

---

From: JK Martin <[email-masked]>
Date: Thu, 8 May 1997 20:40:38 -0400 (EDT)

Tom,

> the Job State table altogether.

This is what Harry explicitly does NOT want to do, right?  (I'm asking
just to make sure I've got these threads straight.)

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

Pending Harry's comments, I could get behind your position if your proposed
changes are in line with the above statements.

We all know that Harry and the others at IBM are busy working on a full
working version of the Job MIB for their products.  How about you folks
at Xerox?  We know that Xerox has a job MIB (or two) of their own, but
what can you tell us about Xerox's experience in prototyping this version
of the standard Job Monitoring MIB?

If you're not prototyping the Job MIB, I would imagine it is difficult
to understand some of the problems raised by Harry and his group.

	...jay

---

From: Harry Lewis <[email-masked]>
Date: Thu, 8 May 1997 21:23:43 -0400

You don't have to replicate jmJobState in the Attribute table since the State
table is defined to have greater persistence.

>> the Job State table altogether.

Further, Jay asked-

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

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

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