implemeting an active alarm table

Dave Mason dmason____transat-tech.com
Fri Sep 20 00:52:30 CEST 2002


Hi,
I'm building a table to maintain a list of currently active alarms. 
 This table must be persistent.  That is, if I shut down my agent and 
restart it, I need the table to contain the same rows that it had 
before.  Does the MibTable class give me this behavior, or do I need to 
use a StorageTable?  The MIB definition for the table does not have a 
StorageType column, but I could make one behind the scenes if I needed 
to.  Also, I have a scalar MIB object associated with the table to 
record a timestamp whenever the alarm table changes (whenever a row is 
added or deleted.)  Does this mean I need to subclass the table off of 
TimeStampTable and use its timestamp?  Maybe I need to inherit from both 
(hopefully not the case), or I need to make my own subclass that does 
both.  I suspect it may be easier to just manage the timestamp object 
myself, but I wanted to make sure I wasnt missing anything.  I use 
AgentGen Pro to make my table class - now it just inherits from MibTable 
but I could change that.

Also, I'm a little rusty on tables.  This table does not have a 
RowStatus column, so does the logic to create it and add/delete rows 
look something like this?

create:
activeAlarmEntry *aae = new activeAlarmEntry();
or can I just use activeAlarmEntry::instance instead of making a new object?

add/delete:
Oidx indexOid("1"); // my index is an Unsigned32
MibTableRow* row = aae->instance->add_row(indexOid);
aae->set_row(row, ...columnar object values...);
or
row = result of search for row with columns equal to desired values
aae->remove_row(row);

Just a couple more questions.  (Hope this isnt too long. :)  When do I 
need to call mib.add(), if at all?  If I do, do I need to update mib 
when I delete a row?  And here's the last - do I need to manage the 
index myself, or is there a way to have the table object just use the 
next higher one when adding a row?  If so, I'll need a way to know what 
the index was.

Thanks for any help you might have,
Dave





More information about the AGENTPP mailing list