Classification:
Tom, thanks for your comments. We need input from some others to help us
finally reach a decision (don't we?)!
I'd just like to clarify one thing. I didn't mean to portray the Attribute
table as only having valid entries for completed jobs. I should rather describe
it as a table of STATIC values as opposed to the state table which is a table
of DYNAMIC values.
An object like jobName would be in the Attribute table as soon as the job is in
any recognizable state. JobName is static and will not change. An object like
ImpressionsCompleted, however, will change throughout the job and makes no
sense to be in the Attribute table until it reaches it's FINAL value. This was
my distinction of the State table as a table of DYNAMIC values and the
attribute table as a table of STATIC values.
Harry Lewis - IBM Printing Systems
------ Forwarded by Harry Lewis/Boulder/IBM on 04/30/97 04:32 PM -----
hastings at cp10.es.xerox.com
04/30/97 01:37 PM
To: Harry Lewis/Boulder/IBM at IBMUS
cc: jmp at pwg.org@internet
Subject: Re: JMP> Why have a Job State Table ?
At 08:23 04/30/97 PDT, Harry Lewis wrote:
>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.
[I changed the name to jmJobStateAssociatedValue, because some reviewers
though that jmJobStateValue was the actual value of the state.]
>>With this note, I'd like to address the issue regarding whether or not to "do
>away with" the Job State Table.
I agree it is the biggest issue(s) remaining.
>>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.
Very helpful.
>>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.
But the attributes in the Attribute table is the same data as the
objects in the Job State table (unless you take the view which you have
later on that the agent only fills in the Attribute table after the job
completes or is canceled - but most of the attribute table has stuff that
is known (and required to be filled in) while the job is pending and
processing, so I think this view is out of date).
So if the data is shared between the two tables, and the persistence is
different between the two tables, the Attribute table has to point to
the data in the State table for the data that is shared. For the Attribute
table that is not shared, the data is in the Attribute table only with
the shorter persistence.
So whats the difference, if we have only the Attribute table. The data
that is persistent for longer, the agent can put it into a different
area of memory, such as if it were in the State table, but there is
no State table accessible vis SNMP. I'm sure there are other methods
of persistence management that clever agent implementors will come up with
as well.
We also have more felixibility in specifying which attribute have the longer
persistence, if all the attributes are only in the Attribute table.
We can just change the spec and say which attributes require the longer
persistence; we don't have to add any objects to the State table (because
there isn't a State table).
SO the agent has to manage one subset of the data with a different
persistence than the rest. Its not on per attribute basis.
The implementation could just have two regions
of memory, one that holds the attributes that have a longer persistence
than the other, but from the application programs point of view it is
one table.
If it helps, we could allocate the jmAttributeTypeTC enums so that
the longer persistent attributes were assigned together at the lower
end of the enum range.
>>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.
There are attributes that a monitoring program must have that are not
in the Job State table, such as jobOwner, etc. So the idea that an
implementation could get away with not implementing the Attribute table
is not valid, even if that implementation was not designed to do accounting.
Also we agreed that the Attribute Table is mandatory
with a small number of attributes as mandatory.
>>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.
Thinking that the Attribute table was only for accounting program is one of
the reasons I was so keen to change the name from AcountingTable to
AttributeTable
in order to avoid misleading people into thinking that the attribute table
was only for accounting. There are a great many attributes that we all
agreed that only make sense for monitoring programs, not accounting programs,
such as pagesCompleted, any of the xxxRequested, any of
xxxCompletredCurrentCopy, any of the xxxRequested
(why would an accounting program care about requested as opposed to completed
or consumed?).
>>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.
I disgree completely. Furthermore, the State table has flaws in that
a monitoring program may need an Associated value for the processing
state (impressionsRequested) when the job has changee to the printing
state and so is no longer available to the monitoring application
for its impression thermometer.
I think it is much better to have a single structure that works for
all applications with pointers to where the active jobs begin (since
monitoring programs are only interested in active jobs),
rather than designing copies of the data structures for two different
applications. Having the same data accessible by different OIDs is
just asking for trouble in implementation of the agent.
>>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?
Because the objects are mandatory. The Attribute table allows a lot
of conditionally mandatory attributes, depending on what kind of a print
system you are monitoring jobs for.
>>We think the 4 groups - General, ID, State and Attribute - are the optimal
>arrangement of objects for Job Monitoring and Accounting.
I disagree.
Rebuttal invited.
Lets here from others too.
>>Harry Lewis - IBM Printing Systems
>>