Jay,
The XPrint 4920 does not implement any unary alerts (e.g.
interpreterCartridgeAdded) since these typically involve a power cycle
or reset, which will clear the alert table.
I would like to propose the following alternative to the new
prtAlertTableChanges object. This alternative requires no new objects
and is fairly simple to implement.
The management application needs to keep track of the OIDs of the
entries in the prtAlertSeverityLevel column. Instead of polling a new
counter object, the management station should periodically do a
GetNext with the OIDs in this column (typically this should fit in a
single PDU). The response will give the severity level of the next new
alert (if there is one) and also let you know when an existing alert
has been removed. Note that if an alert is added and subsequently
removed between polling intervals this method will miss it, but so
will a counter based method. The only real issue with this method is
that if there are many alerts in the table then several PDUs may be
requried to perform the GetNext. But typically this won't be the case
since the alert table is usually close to empty.
Comments?
Thanks,
Angelo
----------
From: owner-pwg at pwg.org
To: binnur at hpb15650.boi.hp.com
Cc: JK Martin; pwg at pwg.org
Subject: RE: Draft of the new prtAlertTableChanges MIB object
Date: Friday, August 02, 1996 6:51PM
Binnur,
> However, talking to our developers here, they are more concern with
> counter incrementing for both critical & warning alerts. As an example,
> even if there is no critical error present, finding out that the toner is
> getting low, or you are out of paper in tray 1 is as important. So, we
> want to filter out everything else from the counter object which are
> informational, or possibly classified as other. This way, we could still
> have only one object added to the MIB, and if the management application
> is interested in all the changes that occurs in the alert table, they
> would simply poll. Any comments from other developers??
I completely understand your interests and concerns. (Really!)
You make it sound like a typical Printer MIB implementation will have
tons of "informational" messages stored in the Alert Table. Is this
really the case, though? (As a software developer, I certainly hope not!)
So, can all of you Printer MIB implementers out there give the PWG some
idea of how many (and what types of) "informational" messages you expect
to insert into the Alert Table? We want to hear from you as soon as
possible.
Incidentally, since informational messages are unary (er, non-binary),
I would think most printer manufacturers would be very cautious about
putting such messages in the Alert Table since they consume valuable
space. Unless a particular manufacturer has some kind of "special" needs
(aka "value-added features") that are perhaps proprietary for special
associated software, I can't imagine this happening...at least not much,
anyway.
> I was thinking in terms of sending a trap out with a alert code that
> indicates that alert table change has occurred (without entering it into
> the alert table). This would be a duplicate entry for critical errors,
> but might be useful for warnings.. Overall, I just wanted to assure we
> have covered all areas in the Printer MIB in terms of adding this new
> object.
Traps? Did you say TRAPS?? Let me quote from the SNMP Book of Life:
"Traps are bad. Traps are to be avoided. Traps should only
be used to indicate truly catastrophic situations, such as
the pending doom of the Earth, or perhaps the reinstatement
of the SDI Program..."
Seriously, though, the use of Traps with the Printer MIB is a complete
and utter mess, not to mention virtually useless for non-NMS management
apps (ie, apps used by other than network managers).
Hey, if you want to add a new Trap--and no one else minds--I guess it
doesn't really matter. Anyone else have an opinion to share on this
topic?
...jay