Certainly, the most useful outcome of the MIB testing should be an
understanding of common usage, details which are not/cannot be fully
documented but which should be handled in a uniform manner.
Harry's question appears to me to relate to the more general question
of 'printer' versus 'subunit'. If a printer has paper that can be
used, it makes no difference that a particular tray may be out. The
status of a given tray should be reported under the input subunit
status indexed to that tray.
The criteria for low paper is not explicit, so that the user may or
may not report printer low paper under this condition. This fuzziness
is perhaps appropriate to a warning condition. Certainly, it would be
hard to quantify what constitutes a paper low condition.
Paper out is somewhat easier to define. But to flag a paper out
warning for a *printer* when the printer still has paper would seem to
be very confusing.
Although the February test will have lots to do, I think the handling
of subunit status is a fairly wide open area for checking consistency.
Bill Wagner, DPI
______________________________ Reply Separator _________________________________
Subject: PMP> Paper Out with Tray linking - Alerts
Author: "Harry Lewis <harryl at VNET.IBM.COM>" <harryl at VNET.IBM.COM> at Internet
Date: 1/22/97 5:12 PM
I guess the short question here is... does anyone think it's a "violation"
to flag a "paper out" WARNING. The key concern being the documented
correlation between hrPrinterDetectedErrorState (1) paperOut and
hrDeviceStatus (5) down.
The longer story...
I've been wrestling with the question of events associated with linked
resources. In general, the question pertains to Input and Output bins that
operate in a sequential manner. If two physical input trays are linked and
the first tray reaches empty there are (at least) 3 alert table options:
1. Treat the linked system as one logical tray that has a paper low
warning.
2. Treat the linked system as 2 physical trays, one of which has a
paper OUT WARNING.
3. Do nothing until the 2nd tray reaches paperLow.
The idea behind (2) is that it would be nice to inform the "operator"
that physical tray 1 is empty although the printer is still fully
operational. The problem with (1) is a very premature warning if 3
trays happen to be linked. I suspect (3) is what most implementations
do today.
Again, the main concern with (2) is that the hrMIB suggests that paperOut
is a down condition not a warning. Are we treating this correlation as
a "hard" expectation or just a recommendation?
Any other comments on how we might like to see this handled?
Harry Lewis - IBM Printing Systems.