Subject: JMP> Output Bin Problems

From: Harry Lewis <[email-masked]>
Date: Thu, 1 May 1997 20:07:07 -0400

Classification:

Tom, a couple comments related to Output Bin and the Job MIB using draft v.81.

 1. Pg. 35 jobStateAssociatedValue is INTEGER. The Associated Attribute for
state COMPLETED cannot be outputBinName, as you have specified. I had specified
outputBinIndex, not Name.

 2. Pg 35. jmStateAssociatedValue is SINGULAR. You have defined attributes
outputBinIndex and outputBinName as Multi-Row. This is probably ok for the
Attribute table but, for the JobStateTable, we need a single value to represent
outputBin when the job is completed. I had specified a simple method as follows:

  -1 Unknown
  -2 Multi
  prtOutputIndex

I believe, as I've stated many times, the jmJobStateTable is very useful for
JOB STATUS MONITORING (not job accounting). For accounting, I can (sorta) see
where you might be interested in the multi-bin facet of outputs used. But, if
you've submitted a job, I believe you want to know it's state, it's progress
and it's final destination. If you asked for collated copies, that final
destination might be (-2 Multi). I think that's enough to know, at that point.

I'd like us to go back to my proposal for outputbin on jmJobStateValue.

3. Pg. 41 You have separate attributes defined for output bin name and number.
Yet, the attribute table is structured such that an attribute type (output bin)
can have either an Integer or String representation. It is not necessary to
have two enums.

Harry Lewis - IBM Printing Systems

---

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

>outputBinIndex, not Name.

I agree I created a problem.  We can't fit an OctetString into 32-bits.

But changing the jobStateAssociatedValue to use outputBinIndex 
brings up another issue, which I'm calling issue 73:

Issue 73 - If outputBinIndex is made mandatory, because the AssociatedValue
object and attribute require it, but an implementation doesn't have the
Printer MIB, the agent has to put 0 as the value.  Should we add one more
attribute: outputBinNumber, which is just a number, not an index into the
Printer MIB?  If we do, which should be mandatory?  Just one more reason to
get rid of the AssociatedValue object and attribute, which is forcing us to
pick a particular outputBin implementation and make it mandatory.  If we got
rid of the AssociatedValue object/attribute, we could forget about making
any of the 3 outputBinName, outputBinNumber, or outputBinIndex attribute
mandatory.

If we get rid of the AssociatedValue object/attribute, then we don't
need to add the outputBinNumber attribute either, since an implementation
can just put in the ASCII digits for the bin number into the outputBinName
attribute.

>I'd like us to go back to my proposal for outputbin on jmJobStateValue.

If we keep the jmJobStateAssociatedValue object and jobStateAssociatedValue
attribute, and agree to have something that fits into 32 bits, we should
have the minus values as you suggest.  (Though I would think we should
use -1 for multi (other), and -2 for unknown, as we do elsewhere in this
MIB and the Printer MIB.

On the other hand, ISSUE 73 is still with us, even if we put in the 
negative values.

>can have either an Integer or String representation. It is not necessary to

I agree, that it isn't necessary to have two enums.  We could have just
one enum, say, outputBin, which allows either the jmAttributeValueAsOctets
(for output bin name) or jmAttributeValueAsInteger (for output bin index).

We could even allow both to be used for the same row.

On the other hand, I think we considered this and decided that it was
cleaner and simpler to have two separate enums, one for the Integer
value and the other for the Octets value.

However, since you raised the issue, I've added it as Issue 74:

ISSUE 74: Collapse pairs of attributes that use Integer vs Octets valus?

Analysis of the 78 attributes shows that there are 8 attribute
pairs that could be collapsed into one attribute with the implementation
using either the Integer or the Octets value (or both) to represent
the attribute.  The application would have to query both value objects.
But if it is using GetNext, it has to get both each time anyway.
Only if it is directly accessing an attribute would it have to get
both values.  On the other hand, it would be fewer Gets than having
two attributes as we have now.
 
The 8 paris are:

physicalDeviceIndex  physicalDeviceName
outputBinIndex       outputBinName
mediumRequestedType  mediumRequestedName
colorantRequestedIndex colorantRequestedName
colorantConsumedIndex colorantConsumedName
jobSubmissionToDeviceDateAndTime  jobSubmissionToDeviceTimeStamp
jobStartedProcessingDateAndTime   jobStartedProcessingTimeStamp
jobCompletedDateAndTime           jobCompletedTimeStamp

Should we collapse them into the following:
physicalDevice
outputBin
mediumRequested
colorantRequested
colorantConsumed
jobSubmissiontToDeviceTime
jobStartedProcessingTime
jobCompletedTime

Should we allow an implementation to fill in both with meaningful values?

---

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

Tom, ... why can't an implementation that does not have the job mib just say
"unknown" for the output bin.
Wouldn't this, indeed, be the case?

------- Forwarded by Harry Lewis/Boulder/IBM on 05/07/97 12:07 PM --------

        [email-masked]
        05/07/97 04:33 AM
Please respond to [email-masked] @ internet

To: Harry Lewis/Boulder/IBM@IBMUS
cc: [email-masked] @ internet
Subject: Re: JMP> Output Bin Problems