PMP> Re: Requested change to HR MIB

PMP> Re: Requested change to HR MIB

charles.a.adams at exgate.tek.com charles.a.adams at exgate.tek.com
Mon Aug 23 19:10:52 EDT 1999


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 at pogo.wv.tek.com


> -----Original Message-----
> From:	harryl at us.ibm.COM [SMTP:harryl at us.ibm.COM]
> Sent:	Monday, August 23, 1999 3:26 PM
> To:	Steve Waldbusser
> Cc:	hostmib at andrew.cmu.edu; pmp at 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 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
> >
> > ----------------
> 
> 
> 



More information about the Pmp mailing list