Subject: RE: JMP> Resource Table - Missile or Camera

From: Tom Hastings <[email-masked]>
Date: Mon, 31 Mar 1997 14:57:38 PST

At 09:42 02/14/97 PST, Harry Lewis <[email-masked]> wrote:
>Ron wrote:
>
>>The more I look at the resource table, the more I agree with Tom
>>that it is a "win-win" situation.  A DPA printer can present every
>>possible parameter and a real-world printer can present only the
>>useful values it can access.  All of this without a large number
>>of objects in the MIB.
>
>I agree! The resource table, with resource type enums, is turning
>out to be a great idea.
>
>One thing I'm finding is that Resource Name seems to be redundant
>with information that should already be in the Printer MIB. I wonder
>how useful resource name is. If we're trying to name a resource like
>OutputBin (3) "Big Bin" - then the name is surely in the printer MIB
>and a server implementation would not be representing this resource.
>If we're trying to get fancy and say MediaType (Paper) "Hillary's
>Pink LetterHead", I really doubt any accounting application will
>be this sensitive. I think a Paper enum (Grade-A, Grade-B etc.)
>for charging purposes is more practical.
>
>Anyone else vie for eliminating Resource Name?
>
>Again, otherwise, I really LIKE the resource table!

So now we have just the following objects in the Attribute table:

The Attribute Group (Mandatory)	78
jmAttributeTypeIndex	80
jmAttributeInstanceIndex	81
jmAttributeValueAsInteger	81
jmAttributeValueAsOctets	82

Ok?

>
>Harry Lewis - IBM Printing Systems.
>
>
>
>

---

From: Tom Hastings <[email-masked]>
Date: Mon, 31 Mar 1997 14:55:18 PST

At 18:11 02/13/97 PST, Harry Lewis <[email-masked]> wrote:
>Lloyd wrote:
>
>>I do not think it is likely that any system will ever fill in the values for a
>>particular resource that are required to process the job before the job starts
>>processing. It would make this whole thing simpler if we changed the first
>>sentence and said "The type of resource, e.g. medium, ink, staples,
>>processing-time, color-impressions, etc. that are consumed while
>>processing the job. This value is updated while the job processes.
>>With this wording change, the resources now are stricly what is
>>consumed in processing the job.
>
>Lloyd, I'd like to agree, but this gets to my original point...
>If you are using SNMP to poll the job table and want to display
>(based on your findings) "Page 1 of 3 is printing" then the
>number of pages requested (3) *has* to be filled out by the agent
>and *cannot* be overwritten as the pages begin to be consumed.

I've tried to clarify the current Internet draft 00.
The description of the JmAttributeTypeTC start off with:

Attributes may represent information about a job, such as a file-name, or a
document-name, or submission-time or completion time.  Attributes may also
represent resources required, e.g., a medium or a colorant , etc. to process
the job before the job start processing OR to indicate the amount of the
resource that is being consumed while the job is processing, e.g., pages
completed or impressions completed.  If both a required and a consumed value
of a resource is needed, two separate attribute enums are assigned in the
textual convention.

Is that clear enough?

>Harry Lewis

---

From: Tom Hastings <[email-masked]>
Date: Mon, 31 Mar 1997 14:46:51 PST

At 14:14 02/13/97 PST, Lloyd Young wrote:
>Bob Pentecost wrote 
>>This brings up another question. jmResourceType says "The type of resource, 
>>e.g., medium, ink, staples, processing-time, color-impressions, etc. 
>>required to process the job before the job start processing.  This value is 
>>updated while the job processes to indicate the amount of the resource that 
>>is being used while the job is processing.  After the job completes 
>>processing, this value indicates the total usage of this resource made by 
>>the job." If a job hasn't started processing, a resource will indicate how 
>>many will be produced. Then, when the job starts processing, the value will 
>>go to zero and count up to three. Is the management application expected to 
>>query jmJobState to know how to interpret the value? If so, should we 
>>define which states cause the value of a resource to change from "required" 
>>to "used"?
>
>processing-time,
>color-impressions, etc. that are consumed while processing the job. This value 
>is
>updated while the job processes ....... ". With this wording change, the 
>resources 
>now are stricly what is consumed in processing the job.

I agree.  Here is what I've clarified the beginning of the jmAttributeGroup
in the Internet Draft 00:

The jmAttributeGroup consists attributes of the job and document(s).
Attribute may represent information about the job and document(s), such as
file-names, document-names, submission-time, completion-time, size.
Attributes may also represent requested and/or consumed resources for each
job.  Instead of allocating distinct objects for each attribute, each
attribute item is represented as a separate row in the jmAttributeTable.
Each column in the row describes the attribute, such as its type represented
as an enum, and the value represented as (1) an integer or (2) an octet
string (character coded text and binary octet strings, such as DateAndTime)
or (3) both.

Ok?

>Lloyd Young
>Lexmark

---

From: Tom Hastings <[email-masked]>
Date: Mon, 31 Mar 1997 14:41:51 PST

At 08:28 02/13/97 PST, Bob Pentecost wrote:
>Harry,
>
>jmResourceType is a read-only object, so how can the job be affected? 
>Wouldn't the object change values only as resources are used?
>

Except for the following, each attribute is either xxxRequested or xxxConsumed,
but not both.  

outputBinIndex	56
outputBinIndex	56
outputBinName	56
sides	56
documentFormatIndex	56
documentFormatEnum	56
physicalDeviceIndex	57
physicalDeviceName	57

In no case is a requested value reset to 0, except for the xxxCurrentCopy
attributes.

jobCopiesRequested	57
jobCopiesCompleted	57
documentCopiesRequested	57
documentCopiesCompleted 57 [glitch in TOC doesn't show this - oops]
jobKOctetsTotal	58
jobKOctetsCompleted	59
impressionsSpooled	60
impressionsSentToDevice	60
impressionsInterpreted	60
impressionsRequested	60
impressionsCompleted	60
impressionsCompletedCurrentCopy	60
pagesRequested	60
pagesCompleted	60
pagesCompletedCurrentCopy	60
sheetsRequested	61
sheetsRequested	61
sheetsCompleted	61
sheetsCompletedCurrentCopy	61
mediumRequested	61
mediumConsumed	61
colorantRequestedIndex	61
colorantRequestedName	61
colorantConsumedIndex	62
colorantConsumedName	62

>
>Bob Pentecost
>HP
>
>
>
>----------
>From:  Harry Lewis <[email-masked]>[SMTP:[email-masked]]
>Sent:  Thursday, February 13, 1997 7:47 AM
>To:  [email-masked]
>Subject:  JMP> Resource table - Missile or Camera
>
>jmResourceTypeTC says (effectively)
>
> "The type (and amount) of resource... required to process the job...the
>  amount is updated while the job processes... etc."
>
>I was starting to wonder if we were "affecting" the job, for example, 
>number
>of copies. But I'm sure we've been very careful to avoid "missiles". Then,
>the purpose of an initial value is to establish a range for metering, like
>copy 1 of 3 has been printed - right? But, if the initial value is 
>overwritten
>per "amount is updated while the job processes...", and the MIB basically
>acts as a data base to be polled, doesn't 1 of 3 fall apart, in which case
>what good would the initial value be?
>
>Sorry if I missed something here.
>
>Harry Lewis.
>
>
>
>
>