Classification:
We're making very good progress on the Job MIB, hopefully, bringing it to
closure soon. Great!
There are some remaining issues, 2 that concern me, namely the Job State Table
and jmJobStateValue.
With this note, I'd like to address the issue regarding whether or not to "do
away with" the Job State Table.
As a refresher, the job state table is indexed by jmJobSetIndex and jmJobIndex
and each entry consists of the State, Octets completed, Impressions completed
and associated State Value which is tailored to contain the most pertinent
information for the current STATE (we'll discuss this separately). The
"argument" for elimination is that all the information in the State Table can
be obtained from attributes in the Attribute Table.
I will try to articulate why I think we should keep the Job State Table.
1. Persistence. The JobState table has a longer persistence than the Attribute
table. It is simpler for the agent to manage groups of objects on a per job
basis associated with a given table persistence than it is to manage each
object with a separate
persistence value.
2. Job Monitoring (progress, completion etc.) vs. Job Accounting. We used to
call the Attribute Table the Accounting Table. The Job State table can be
thought of as facilitating Job Monitoring while the Attribute table serves the
Accounting application. I think we should ask ourselves if there is any value
in some printer that implements the State table but not the Attribute Table -
i.e. facilitates Job Monitoring but not accounting. If so, then the separate
Job State table could really be of value to "low end" implementation. Recall
the Attribute table will be the largest consumer of memory for the agent and
has a more complex indexing scheme.
3. Dynamics - Maybe we are operating from a mind set established back when we
used to call the Attribute Table the Resource Accounting Group... but we view
the JobState table as a group where objects are updated dynamically as the job
progresses but the Attribute (Accounting) table as something that is updated
upon job completion. Accounting applications are not interested in the PROGRESS
of a job - only the resulting details. An accounting application wants to
determine Job Complete (State Table) and then
"harvest" the accounting (attribute) information - ONCE. Dynamic objects, which
have not reached their final state or value, are of little value to an
accounting application.
All three statements reflect one "philosophy". The job MIB lets you Monitor and
do Accounting. Does anyone think it has another purpose? Since these purposes
are distinct, the structure of the MIB reflects this.
The argument that everything can be found in the Attribute table and separate
persistence values can be given to each object etc. may be a good one and
perhaps it reflects better knowledge of SNMP than we had during design of the
Printer MIB but - to draw an analogy - why isn't the printer MIB just one big
table of printer Attributes instead of input, output, marker etc. groups?
We think the 4 groups - General, ID, State and Attribute - are the optimal
arrangement of objects for Job Monitoring and Accounting.
Harry Lewis - IBM Printing Systems