PMP Mail Archive: Re: PMP> Top 25 minus 4 conditions/alerts proposal

PMP Mail Archive: Re: PMP> Top 25 minus 4 conditions/alerts proposal

Re: PMP> Top 25 minus 4 conditions/alerts proposal

Caruso,Angelo (
Fri, 2 May 1997 08:18:13 PDT


I like your proposal (I'll repeat it here for those who did not read
your entire message):

> Here's a proposal to fix that problem that results in the reversal
> of consensus reached in the last telecon:
> If the printer automatically goes offline when one of
> the 16 defined top conditions is encountered, then the
> hrPrinterDetectedErrorState variable is set to "offline".
> In this case, no "offline" alert should be added to the
> Alert Table.
> When a condition occurs that causes the printer to automatically
> go offline, a critical alert is added to the Alert Table, and
> the alert code reflects the specific nature of the condition.
> The only time an "offline" alert is added to the Alert Table
> is when the printer is directed to go offline by management
> control, either remotely or locally, from the front panel.

Also, for the record, I think forcing the printer "off-line" when
critical alerts occur is uneccessary and annoying to users. Why should
I have to remember to press a button after I add paper, clear a jam or
add toner??? By the way, my definition of off-line is that the device
will not accept new jobs from any channel, but will complete any job
already in process.

Regarding Gail's earlier posting about the low toner bit being only a
warning, the description of hrPrinterDetectedErrorState basically
dictates that low toner can only be a warning. Obviously this is
inconsistent with existing implementations. And, what about alerts
which have no defined bits? It's seems logical to use the generic
"serviceRequested" bit. But, again the description dictates that this
can only be a warning. So, I propose that the Printer MIB, section, should state that the table in the description for
hrPrinterDetectedErrorState is inconsistent with existing
implementations and that the value of hrDeviceStatus for a given bit
in hrPrinterDetectedErrorState is implementation specific. What do you think?