PMP Mail Archive: RE: PMP> Re: Requested change to HR MIB

PMP Mail Archive: RE: PMP> Re: Requested change to HR MIB

RE: PMP> Re: Requested change to HR MIB

charles.a.adams@exgate.tek.com
Mon, 23 Aug 1999 16:10:52 -0700

I would like to second Harry's statements. The current wording looks
too much like a specification. I think this is best handled in
comments as information to developers. Implementations vary
too much to imply that this is anything more than a guide.

Tektronix, Inc.
Color Printing and Imaging Division
adamsc@pogo.wv.tek.com

> -----Original Message-----
> From: harryl@us.ibm.COM [SMTP:harryl@us.ibm.COM]
> Sent: Monday, August 23, 1999 3:26 PM
> To: Steve Waldbusser
> Cc: hostmib@andrew.cmu.edu; pmp@pwg.org
> Subject: Re: PMP> Re: Requested change to HR MIB
>
>
>
> 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@us.ibm.com
>
>
> Steve Waldbusser <waldbusser@ins.com> on 08/23/99 01:53:03 PM
>
> To: hostmib@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@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@lexmark.com Lexington, KY 40550-0001
> > Phone: (606) 232-5150 Fax: (630) 982-4032
> >
> > ----------------
>
>
>