Subject: JMP> Resource table - Missile or Camera

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Thu, 13 Feb 97 07:47:26 MST

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.

---

From: Bob Pentecost <[email-masked]>
Date: Thu, 13 Feb 1997 09:28:41 -0700

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?

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

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

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?

Harry Lewis.

---

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Thu, 13 Feb 97 13:42:54 MST

Bob,

>jmResourceType is a read-only object, so how can the job be affected?

Thanks for pointing that out.

>This brings up another question. ...................                    ce,
>......... If a job hasn't started processing, a resource will indicate how

You've done a better job at stating my observation. My recommendation
is to separate values which are passed in from values that will vary
during the job.

Harry Lewis

---

From: Lloyd Young <[email-masked]>
Date: 13 Feb 97 17:14:26 EST

Bob Pentecost wrote 
>define which states cause the value of a resource to change from "required" 

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 Young
Lexmark

---

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Thu, 13 Feb 97 19:11:37 MST

Lloyd wrote:

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

Harry Lewis

---

From: Ron Bergman <[email-masked]>
Date: Fri, 14 Feb 1997 08:25:01 -0800 (PST)

One of my original concepts was to overload the resource objects and
have the values represent the requested value prior to the printer 
processing the job and the actual value after.  The primary reason 
was to minimize the number of objects.  When these objects were 
deleted and replaced with the resource table, this idea had no 
advantages and was abandon.  The Resource Enums were to be unique
for "requested" and "actual" values.  In reviewing the current
specification I notice that in some cases this is not true.  For
example, sides(9) can be either requested or used.  This should be
changed to be consistent.  I will review the current set of enums
and correct where necessary.

I agree that in most cases the only values presented will be the
"actuals".  (This is why I originally proposed overloading the
objects.)   However, with the Resource Table, the printer can 
present only those values desired and the number of objects will
be a minimum.  In the rare case of a DPA printer, the entire set
of resource enums can be returned.

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.

	Ron Bergman
	Dataproducts Corp.
	[email-masked]
	(805) 578-4421

---

From: "Harry Lewis <[email-masked]>" <[email-masked]>
Date: Fri, 14 Feb 97 10:42:29 MST

>useful values it can access.  All of this without a large number

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!

Harry Lewis - IBM Printing Systems.