Tom... I thought you'd never ask!
>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.
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
D sheetsCompletedCurrentCopy 54
D mediumConsumedName 55
D colorantConsumedIndex 55
D colorantConsumedName 55
D jobProcessingCPUTime 57
Category X - "Who needs this Anyway"
D jobKOctetsTransferred (mandatory) 51
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
D pagesCompletedCurrentCopy 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
D impressionsCompletedCurrentCopy 53
The StateValue for printing that I had defined was CurrentCopy. Somehow,
it got changed in your MIB to impressionsRequested... which is a STATIC
attribute.
Harry Lewis - IBM Printing Systems