>What makes this critical alert different than others? As a critial alert,
>absolutely nothing. The key point here is that we now have a particular
>alert condition ("toner low") that can be either a critical or non-critical
>alert, depending on the precise state of the printer at any given time.
>That's new for us, right? Until now, a vendor would pretty much fix the
>severity level for any given alert code, at least from what we've seen in
>our testing.
> ...jay
...but we're already dealt with a similar case - the linked input tray.
We asked ourselves what to do if a tray runs empty but that tray forms
part of a larger "logical" linked tray. We said, in this case, there
should be a subUnitEmpty WARNING. If the tray were not linked, and
the printer was calling for paper from this tray, there would be a
subUnitEmpty CRITICAL.
I know Bob P. was trying to provide a clarification regarding the (very
real) toner low (critical) vs. toner low (continue) situation... I
really appreciate that. And I suspect Bob introduced the notion of
focusing on OFF-LINE to try and "get around" the "broken" hrMIB. I
appreciate that, too. But, having gone this far down the road with this
topic, I think we'd be better off separating off-line from the discussion
and just decide to treat alerts that stop the printer as critical and
alerts that don't as warnings. As Stuart noted, we need to preserve the
alert table's integrity and not succumb to inherited hrMIB deficiencies.
I don't think anyone, even the designers of the hrMIB, would want, or
expect their MIB to prevent the printer MIB from reflecting reality.
Harry Lewis - IBM Printing Systems