Subject: JMP> Why have a Job State Table ?

From: Harry Lewis <[email-masked]>
Date: Wed, 30 Apr 1997 11:23:10 -0400

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

---

From: Tom Hastings <[email-masked]>
Date: Wed, 30 Apr 1997 11:33:29 PDT

>There are some remaining issues, 2  that concern me, namely the Job State Table

[I changed the name to jmJobStateAssociatedValue, because some reviewers
though that jmJobStateValue was the actual value of the state.]

>away with" the Job State Table.

I agree it is the biggest issue(s) remaining.

>I will try to articulate why I think we should keep the Job State Table.

Very helpful.

>basis associated with a given table persistence than it is to manage each

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.

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

>have not reached their final state or value, are of little value to an

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

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

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

>arrangement of objects for Job Monitoring and Accounting.

I disagree.

Rebuttal invited.

Lets here from others too.

---

From: Harry Lewis <[email-masked]>
Date: Wed, 30 Apr 1997 18:41:39 -0400

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.

------ Forwarded by Harry Lewis/Boulder/IBM on 04/30/97 04:32 PM -----

        [email-masked]
        04/30/97 01:37 PM

To: Harry Lewis/Boulder/IBM@IBMUS
cc: [email-masked]@internet
Subject: Re: JMP> Why have a Job State Table ?

Very helpful.

I disagree.

Rebuttal invited.