Re: 'Inter-Tables indexing' and perl

On Fri, 2005-10-14 at 14:21 +0200, Turbo Fredriksson wrote:

> But if I understand you correctly, [the client table] should
> be split into two tables, one with the client info and one
> with the job name info?

Yup.
Everything at the same level of nesting can be grouped into the
same table.  Different levels of nesting imply different tables.


> So, to recap and see if I understood you correctly:
> 
>     # The table with the client info, index from clientsTable
>     $ snmpwalk clientsTable
>     client1 = client1
>     client2 = client2
>        :

Yup.
   [But see below at (*)]


>     # The table with the job names, index from clientsTable AND jobsTable
>     $ snmpwalk jobsTable
>     client1.job1 = job1
>     client1.job2 = job2
>        :
>     client2.job1 = job1
>     client2.job2 = job2
>        :

Yup.
   [But see (*) again]

>     # The table with the stats info, index from clientsTable,
>     # jobsTable AND statsTable
>     $ snmpwalk statsTable
>     stat1.client1.job1.id1 = start date
>     stat1.client1.job1.id2 = start date
>     stat1.client1.job2.id1 = start date
>     stat1.client1.job2.id2 = start date
>        :
>     stat1.client2.job3.id3 = start date
>     stat2.client1.job1.id1 = end date
>     stat2.client1.job1.id2 = end date
>        :
>     stat5.client2.job3.id3 = bytes

Yup.

<Professor Higgins>
   By Jove, I think he's got it!
</Professor Higgins>

> Hm, you put the 'statX' differently than I had expected. I
> would have (did earlier this week) swap the 'statX' and 'idX' parts.

But 'statX' isn't an index to the table. It's one of the columns.

SNMP (or strictly SMI) ordering is defined to walk tables in
column-major order, rather than the (perhaps more natural)
row-major order.   It does make sense when you think about
walking the columns of a table in parallel
   ("snmpgetnext stat1 stat2 stat3 stat4 stat5")
rather than serially, but often comes as a surprise to those
new to SNMP.


> Thanx for the help. Did I get it right this time around?

Yup.


Now for the (*):

Walking an SNMP table would *not* (normally) display the index
values.  So the first two table outputs wouldn't typically be
as shown above - repeating the indexes as the column values.

Assuming that you have other information that you need to report
about each client system (and about each individual named jobs),
then walking either of these tables would only display this other
information - not the client/jobName values (other than as part of
the indexing for that table).

I.e.:
    $ snmpwalk clientTable
    clientDescr.client1 = "Description of 'client1'"
    clientDescr.client2 = "Description of 'client2'"
    clientContact.client1 = "Poor sod in charge of 'client1'"
    clientContact.client2 = "Poor sod in charge of 'client2'"


   (and similarly for the jobTable)
If there isn't any other information required (at either level)
then the corresponding table can be dropped, and the relevant index
moved into the next table (but still defined as "not-accessible").

So if you *just* need to report the statistics (and nothing else),
then you'd end up with a single statsTable, defined (and
simplified) somewhat as follows:

    baculaStatsTable   OBJECT-TYPE
       SYNTAX          SEQUENCE OF BaculaStatsEntry
          :
    ::= { baculaStats 4 }

    baculaStatsEntry   OBJECT-TYPE
       SYNTAX          BaculaStatsEntry
       INDEX           { bCName, bJName, bJId }
          :
    ::= { baculaStatsTable 1 }

    BaculaStatsEntry ::= SEQUENCE {
        bCName         OCTET STRING,
        bJName         OCTET STRING,
        bJId           OCTET STRING,
        stat1          OCTET STRING,
          :
        stat5          OCTET STRING
    }

    bCName             OBJECT-TYPE
      MAX-ACCESS       not-accessible
         :
    ::= { baculaStatsEntry 1 }

    bJName             OBJECT-TYPE
      MAX-ACCESS       not-accessible
         :
    ::= { baculaStatsEntry 2 }

    bJId               OBJECT-TYPE
      MAX-ACCESS       not-accessible
         :
    ::= { baculaStatsEntry 3 }

    stat1              OBJECT-TYPE
      MAX-ACCESS       read-only
         :
    ::= { baculaStatsEntry 4 }

              :

    stat5              OBJECT-TYPE
      MAX-ACCESS       read-only
         :
    ::= { baculaStatsEntry 8 }



Which is similar to what you had initially, but not
quite the same.

Have I managed to confuse you again?

Dave


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users