>Again, thanks for the response, Bob. No matter what how you respond to my
>above question, this kind of information is crucial for software developers
>as we try to deliver products based on the Printer MIB.
>
> ...jay
I imagine, like IBM, most printer vendors have alert table specifications
that include hrDeviceStatus, hrPrinterStatus and hrPrinterDetectedErrorState
columns as well as the typical Alert Code, Severity, Group, Group Index etc.
While the LOCATION column will be very different between vendors (by design)
there is likely to be a high degree of similarity in the tables.
Would it make sense to share these tables as part of recovery from the
bakeoff "status" findings? Do other vendors consider their alert specs
proprietary?
We are willing to submit our alert/status table to the PWG as a basis for
standardization and or discussion to encourage this effort.
If you don't think we really have a problem that needs this sort of attention,
just look at several of today's relevant postings...
>We have error and warning conditions that are not covered by the eight
>conditions listed for hrPrinterDetectedErrorState. For example, a disk
>failure or a failure in the controller that interfaces to our paper
>handling devices.
>
>Bob Pentecost
>HP
***********
> I would suggest that a disk problem is reported in the hrDeviceStatus
> for the disk device, not in the hrPrinterDetectedErrorState.
>
> Bill Wagner DPI
***********
> We use hrPrinterDetectedErrorState bit 7 in cases such as these
>
> Harry Lewis - IBM Printing Systems
***********
>Offline is the key; if it is set then there is a good possibility that
>something else is wrong.
>
>Gail
Harry Lewis - IBM Printing Systems