At 15:41 04/30/97 PDT, Harry Lewis wrote:
>Classification:
>>Tom, thanks for your comments. We need input from some others to help us
>finally reach a decision (don't we?)!
We sure do need others input. In the meantime, lets keep up the dialog,
because I think that we still have some different understandings about this
MIB and the dialog will help flush out those different understandings.
>>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.
To test your assertion that the Attribute table could be clarifed as only
having values after they reach a final STATIC value, here is the entire
TOC. I've labeled with S or D each attribute to indicate STATIC versus
DYNAMIC test your assertion that the Attribute table only contains
STATIC attribute and the Job State table should be the only place
for DYNAMIC attributes. The entries with D* are also accessible through
the Job State table.
However, there are 26 DYNAMIC attributes, i.e., 26 attribute are likely
to have their value change as the job progresses out of a total of 78
attributes. The current Job State table only provides access to 9 DYNAMIC
attributes out of a possible 26. Therefore, I do not
see the Attribute table as only containing STATIC values after they
reach a final value and the job state table being the only place that
changes the values as the job progresses, i.e, the only place for
DYNAMIC values. So unless we change our minds and throw away 26-9=15 of these
26 DYNAMIC attributes, a monitoring program is going to be very interested
in the attribute table and the attributes in it that are changing.
That is why I have been questioning the wisdom of also having the Job State
Table. Besides I'd also like to see us reduce the number of mandatory
objects by another 30%, (go from 13 to 10, by dropping the Job State table),
have only one way to access information (the Attributes Table), and avoid
the agent complexity of the same data appearing in more than one table.
S=STATIC, D=DYNAMIC, D*=DYNAMIC and accessible through the Job State Table
JmAttributeTypeTC - attribute type definitions 34
other 37
unknown 38
Job State attributes 38
D* jobState (mandatory) 38
D* jobStateAssociatedValue 38
D jobStateReasons1 39
D jobStateReasons2 40
D jobStateReasons3 40
D jobStateReasons4 41
D* numberOfInterveningJobs (mandatory) 41
D* deviceAlertCode (mandatory) 41
D processingMessage 41
Job Identification attributes 41
S serverAssignedJobName 41
S jobName 42
S jobServiceTypes 42
S jobOwner 43
S jobAccountName 43
S jobSourceChannelIndex 43
S jobSourcePlatformType 43
S submittingServerName 44
S submittingApplicationName 44
S deviceNameRequested 44
S queueNameRequested 44
S physicalDeviceIndex 44
S physicalDeviceName 45
S numberOfDocuments 45
S fileName 45
S documentName 45
S jobComment 45
S documentFormatIndex 46
S documentFormatType 46
Job Parameter attributes 47
S jobPriority 47
S jobProcessAfterDateAndTime 47
S jobHoldUntil 48
S outputBinIndex 48
S outputBinName (mandatory) 48
S sides 48
S finishing 48
Image Quality attributes (requested and used) 48
S printQualityRequested 48
S printQualityUsed 49
S tonerEcomonyRequested 49
S tonerEcomonyUsed 49
S tonerDensityRequested 49
S tonerDensityUsed 49
Job Progress attributes (requested and consumed) 49
S jobCopiesRequested 49
D jobCopiesCompleted 49
S documentCopiesRequested 50
D documentCopiesCompleted 50
S jobKOctetsRequested (mandatory) 50
D jobKOctetsTransferred (mandatory) 51
D* jobKOctetsCompleted (mandatory) 51
Impression attributes (requested and consumed) 52
D impressionsSpooled 52
D impressionsSentToDevice 52
D impressionsInterpreted 52
S impressionsRequested (mandatory) 52
D* impressionsCompleted (mandatory) 52
D impressionsCompletedCurrentCopy 53
Page attributes (requested and consumed) 53
S pagesRequested 53
D pagesCompleted 53
D pagesCompletedCurrentCopy 53
Sheet attributes (requested and consumed) 53
S sheetsRequested 54
D sheetsCompleted 54
D sheetsCompletedCurrentCopy 54
Resource attributes (requested and consumed) 54
S mediumRequestedType 54
S mediumRequestedName 54
D mediumConsumedName 55
S colorantRequestedIndex 55
S colorantRequestedName 55
D colorantConsumedIndex 55
D colorantConsumedName 55
Time attributes (set by server or device) 56
S jobSubmissionToServerDateAndTime 56
S jobSubmissionToDeviceDateAndTime 56
S jobSubmissionToDeviceTimeStamp 56
S jobStartedBeingHeldTimeStamp 57
S jobStartedProcessingDateAndTime 57
S jobStartedProcessingTimeStamp 57
S jobCompletedDateAndTime 57
S jobCompletedTimeStamp 57
D jobProcessingCPUTime 57
>>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
>>>>>>>>>>