Implementations had found a few cases where the fixed association between
hrPrinterDetectedErrorState bits and hrDeviceStatus were inappropriate. The
initial recommendation was to add warning or down for each bit. Later, we
requested to just REMOVE the hrDeviceStatus column altogether since
SPECIFICATION of an association was not feasible in all circumstances.
If the new wording is clear that these are LIKELY associations but not mandated,
I guess that's ok too, but I'd rather see this as an example. I believe the
current draft appears too much like a specification (that MUST be followed).
Harry Lewis
IBM Printing Systems
harryl at us.ibm.com
Steve Waldbusser <waldbusser at ins.com> on 08/23/99 01:53:03 PM
To: hostmib at andrew.cmu.edu
cc:
Subject: PMP> Re: Requested change to HR MIB
This problem was solved a different way.
The new text (ini the current draft) clarifies that "The hrDeviceStatus column
shows the hrDeviceStatus which is typically appropriate when such an error
condition exists." In other words, there isn't a strict algorithmic
translation between errorState bits and deviceStatus. deviceStatus should be
set based on the operational status of the printer. errorState bits should be
set based on any detected errors. If the noPaper condition is set but the
printer is still able to run, this would be highly unusual, but OK. The
deviceStatus column just suggests the most likely condition.
Adding warning or down to all rows is less useful and actually provides less
flexibility than implementors might need.
Steve
> From: lpyoung at lexmark.com>> Please change the description of hrPrinterDetectedErrorState:
>> Original Text
> Condition Bit # hrDeviceStatus
>> lowPaper 0 warning(3)
> noPaper 1 down(5)
> lowToner 2 warning(3)
> noToner 3 down(5)
> doorOpen 4 down(5)
> jammed 5 down(5)
> offline 6 down(5)
> serviceRequested 7 warning(3)
> inputTrayMissing 8 warning(3)
> outputTrayMissing 9 warning(3)
> markerSupplyMissing 10 warning(3)
> outputNearFull 11 warning(3)
> outputFull 12 warning(3)
> inputTrayEmpty 13 warning(3)
> overduePreventMaint 14 warning(3)
>> Revised Text
> Condition Bit # hrDeviceStatus
>> lowPaper 0 warning(3) or down(5)
> noPaper 1 warning(3) or down(5)
> lowToner 2 warning(3) or down(5)
> noToner 3 warning(3) or down(5)
> doorOpen 4 warning(3) or down(5)
> jammed 5 warning(3) or down(5)
> offline 6 warning(3) or down(5)
> serviceRequested 7 warning(3) or down(5)
>> inputTrayMissing 8 warning(3) or down(5)
> outputTrayMissing 9 warning(3) or down(5)
> markerSupplyMissing 10 warning(3) or down(5)
> outputNearFull 11 warning(3) or down(5)
> outputFull 12 warning(3) or down(5)
> inputTrayEmpty 13 warning(3) or down(5)
> overduePreventMaint 14 warning(3) or down(5)
>> Reason for change:
> The original text would seem to require all printers to respond
> identically in hrDeviceStatus on the same error condition. Reality
> is that different printers respond differently on the same error
> condition. What might be a warning in one printer may be a down
> condition in another printer. Even within a printer a single error
> condition might be a warning one time and a down condition another
> time. For example, several printers support the linking of multiple
> paper trays together to form one logical paper tray, when one of the
> linked trays runs out of paper the printer will start feeding paper
> from one of the other linked trays, the printer may report noPaper
> but it is a warning condition because paper is being fed from
> another tray.
>> Lloyd
> ------------------------------------------------------------
> Lloyd Young
> Manager, Alliances and Complementary Project Development
> Consumer Printer Division Lexmark International, Inc.
> Dept. C88M/Bldg. 005-1 740 New Circle Road NW
> email: lpyoung at lexmark.com Lexington, KY 40550-0001
> Phone: (606) 232-5150 Fax: (630) 982-4032
>> ----------------