Draft of the new prtAlertTableChanges MIB object

Draft of the new prtAlertTableChanges MIB object

Draft of the new prtAlertTableChanges MIB object

Bob Pentecost bpenteco at boi.hp.com
Fri Aug 2 16:19:14 EDT 1996

My notes show that we were going to have one counter for critical alerts 
and another for non-critical alerts. By having separate counters, the hosts 
that are polling for critical alerts won't have to be bothered by all the 
other stuff in the alert table.

Bob Pentecost

From:  JK Martin[SMTP:jkm at underscore.com]
Sent:  Thursday, August 01, 1996 4:59 PM
To:  pwg at pwg.org
Subject:  Draft of the new prtAlertTableChanges MIB object

Following is a draft of the proposed new Printer MIB object describing
changes to the Alert Table, as discussed at the recent PWG July meeting.

    prtAlertTableChanges OBJECT-TYPE
	SYNTAX      Counter32
	MAX-ACCESS  read-only
	MIN-ACCESS  read-only
	STATUS      current
	    "Counts the changes made to the Alert Table in a manner similar
             to the prtGeneralConfigChanges object.  This value is 
             whenever an entry is added to or removed from the table, or if
             an existing entry is changed in any way.  By monitoring this
             object a management application should be able to quickly and
             decisively determine when the Alert Table has changed; upon
             recognizing a change, the application should acquire the 
             Alert Table to determine the precise nature of the change."
	::= { prtGeneralEntry 16 }

Note carefully that I've placed this object in the prtGeneral Group.
This was chosen to reflect similar kinds of info already existing in
the General Group, although I don't really care where it goes in the
MIB.  (Is it legal/tasteful to put this object as a peer to an "Entry"
definition within a Table?  Or as a peer to the Table? For example,
"{ prtAlertTable 2 }" or "{ prtAlert 2}" ??)

Any help on improving the DESCRIPTION clause would be appreciated!


More information about the Pwg mailing list