This is a discussion on Re: Can two MIB Tables be related and be required to share the same - SNMP ; On Thu, 31 May 2007 11:17:22 -0700 (PDT) Need wrote: NH> OK, so I need to use the same index for Table2 as I used in Table1, but I do not know how to actually do this? Well, you've stepped ...
On Thu, 31 May 2007 11:17:22 -0700 (PDT) Need wrote:
NH> OK, so I need to use the same index for Table2 as I used in Table1, but I do not know how to actually do this?
Well, you've stepped out of the bounds of a 'simple' table, so Mad won't
auto-generate nice neat ready to use code. However, there is an example of MfD
+ shared indexes - ifTable and ifXTable. Basically, they share a single
container. Since you have sparse secondary tables, that won't quite work for
NH> Here is what I am doing to create Table1 currently.
NH> In the "container_load()" routine I perform the following steps to populate all requried indices in the ocStbHostAVInterfaceTable:
NH> 1) Obtain a unique NetSNMP index:
NH> 2) Indicate the index has been reserved for the ocStbHostAVInterface table:
NH> 3) Allocate new a row for the table:
NH> 4) Store the index into the row:
NH> 5) Populate the rest of the data table fields now for Table1:
NH> Now, it is time to create Table2.
NH> Inside the "container_load()" routine of Table2, I do not believe I want to perform any of the 4 steps above, since I do not want to generate a new index or new row for Table2 entries .... correct?
NH> If no new index and no new row should be created for Table2, then I am not sure how to obtain the internal NetSNMP index (ie: ocStbHostAVInterfaceIndex) previously generated and stored for Table1.
NH> Is there a way in which I could loop through all rows of Table1? If so, then I could loop through each row of Table1 to find which "ocStbHostAVInterfaceType" fields are set to the "1394" interface enum (since Table2 is only related to "1394" interface data).
Yes, a container iterator (or the FOR_EACH macro) can be used to loop through
However, I suggest a different approach. A container can have a linked list of
sub-container, and those subcontainers can have an associated insert_filter.
So, the first/primary table would create not just 1 container, but 1 + N for
each of the secondary/sparse related tables. Each of the secondary containers
would define a filter such that only the appropriate row indexes would end up
in that container. Then each of the secondary tables would use the associated
sub-container from the primary table, instead of creating their own.
Now having said that, there aren't any examples of using subcontainers with
filters, and I can't even recall using one myself, but this is exactly the
scenario that insert_filters were written for.
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Net-snmp-coders mailing list