Subject: Re: JMP> Why have a Job State Table ?

From: Tom Hastings <[email-masked]>
Date: Wed, 7 May 1997 03:27:54 PDT

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

---

From: Harry Lewis <[email-masked]>
Date: Wed, 7 May 1997 14:05:35 -0400

Tom... I thought you'd never ask!

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

And, I never thought you'd be so Bold! ;-)

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

I'm using some levity, of course, but, honestly, Tom, as I was reading
your msg, before I even got to your list, I was betting you had done an
excellent job categorizing which attributes are clogging the Job MIB
arteries. And you HAVE, almost to a tee.

With this posting, I think you've really hit the nail squarely and
reveled the key remaining discussion topic.

I've been uneasy about all these attributes but I always suppress it with
the argument I know I'll hear... attributes are not mandatory so why not
"PILE ON". And, why limit the MIB - if someone wants to use it to shoot
printers into outerspace - let them. I've even thought about adding a few
attributes to try and make my point... let's see...

For starters, how about jobStateReasons5,6,7,8 and 9?
Then we could add... currentOctetBeingExaminedByPDLInterpreter

Tom, my "jovial" disposition is probably not coming across well in this
note. This is not meant as a "slap". I just hardly know where to take
this, anymore. While you and I are in strong agreement for most of the
Job MIB, it should be obvious, we have vastly differing opinions regarding
use of the State and Attribute tables. I understand how bogged down we all
get with this PWG mail, so we may not really hear from others until the
meeting next week. I'd like to encourage anyone interested in resolution
of the topic to consider these issues and come prepared with your
position to the meeting.

Below, I'll do *my* categorization of the 29 attributes you listed as
dynamic and having no home if we try to keep the Attribute table static.

Category A - "Why does this need to be Dynamic?"

 Yes, the attributes in this category are "dynamic", but are the
 dynamics really interesting or useful? I consider these attributes
 static, or at least discrete... in that they are not changing as
 the job progresses as much as they have some (potentially) useful
 meaning any time the job STOPS progressing.

D    jobStateReasons1 39
D    jobStateReasons2 40
D    jobStateReasons3 40
D    jobStateReasons4 41

 Is the REASON that a job is pending, printing, processing or completed
 an interesting attribute? I say NO! Perhaps we should change the
 StateValue for HELD to REASON rather than TIME, I could live with that
 (*please* don't say there could be 10 reasons why the job got held!).
 In the NeedsAttention state, we already have a StateValue showing the
 alert code. The only remaining state is Canceled - final state - where
 the REASONS are not going to CHANGE.

D    processingMessage 41

 Similarly - are we wanting to catch messages as they fly by during
 normal operation? NO!

D    sheetsCompleted 54

Category X - "Who needs this Anyway"

 I thought we had agreed that Octets were too elusive for most agents and
 we would focus on impressions. Also, this brings us into the granularity
 discussion. There go my octets... they're being transferred... now they're
 buffered... oh, look, they are entering the PDL interpreter... and finally
 being laid to rest on the drum... making a fine impression, indeed.

D    pagesCompleted 53

 I thought we had pretty much agreed pages were too elusive for most
 agents and we would focus on impressions.

D    impressionsSpooled 52
D    impressionsSentToDevice 52
D    impressionsInterpreted 52 (This is the only one I might agree with you on).
D    documentCopiesCompleted 50

Category Y - "I think these are covered by StateValues."

D    jobCopiesCompleted 49

The StateValue for printing that I had defined was CurrentCopy. Somehow,
it got changed in your MIB to impressionsRequested... which is a STATIC
attribute.

---

From: JK Martin <[email-masked]>
Date: Wed, 7 May 1997 14:46:15 -0400 (EDT)

Harry,

As you know all too well, I'm in general agreement with the overall
nature of your message.

It was hard for me to tell, based on your text, whether you were
proposing that some of the defined attributes should be removed.
Is this the case?  Or were you suggesting those attributes should
be placed in a new "home" (ie, somewhere else in the MIB)?

> Category X - "Who needs this Anyway"

I believe *some* of these attributes are very useful:

  sheetsCompleted
	Perhaps the only meaningful value to the end-user in terms of
	estimating when the job will finish, given that client software
	sending the job to the printer often has no idea of the total
	sheets to be printed.  (This value reflects the *total* sheets
	printed for job thus far, right?)

  mediumConsumedName
	For accounting purposes, this may be the most processable element
	to account for media costs/planning.  Consider the infamous PWG
	example of "Hillary's pink letterhead"; even though the media size
	may be Letter, the cost of this media may very well be higher than
	plain old 20-pound Letter copier paper.

  jobProcessingCPUTime
	One of my personal favorites.  A 20-sheet job from a software
	engineering department is usually quite a bit different from
	a 20-page job from a Graphic Arts department.  When it comes to
	capacity planning purposes, this value can be extremely useful
	in determining resource requirements based on application usage.

When I step back and look what I've just written, it occurs to me that
one of the biggest problems I have with the Job MIB draft is that it
provides a plethora of descriptive text telling the reader WHAT the object
is...yet very seldom tells the reader WHY it's important, or HOW it can
be used to solve common critical problems.  (Or is such knowledge considered
to be a "proprietary advantage" by some?)

> it got changed in your MIB to impressionsRequested... which is a STATIC

This kind of situation happens all too frequently, IMHO.  It has also
caused significant delay in progressing this effort, while others in
the group "discover" such changes in the text.  Let us NOT DO THIS anymore.

By the way, I'm still hoping to see a simple summary of minimum
conformance  published, whereby all mandatory items can be identified
so as to give us an idea of the level of effort to develop a minimum
conforming implementation.

	...jay