Question about table index

[Bettendorf, Cristian]

Hello Frank,

yes, all right, I use actually read-only index definitions and all works
fine.

But before I go public with my application I want to be shure that my
implementation and MIB design don't break SMIv2 specs. and the way I solve
the problems is accepted by the SNMP community. 

How are such problems solved by other implementors? It make no sense to
write the MIB using SMIv1 since converting to SMIv2 will be hard or
impossible (SMIv2 converting to SMIv1 is allmost easy).

Rgs. Cristian

-----Original Message-----
From: Frank.Fock____t-online.de [mailto:Frank.Fock____t-online.de]
Sent: Freitag, 24. August 2001 01:20
To: Bettendorf, Cristian
Cc: 'agentpp-dl____agentpp.com'
Subject: Re: Question about table index


Hello Christian,

I saw the corresponding thread in comp.protocols.snmp, so I am
only discuss additional aspects below:

"Bettendorf, Cristian" wrote:

> Hello,
>
> a short question not related to agent++...
>
> In SMIv2 the columnar objects part of the table index must be defined as
> "not-accesible".
>
> In my case I MUST read the values in order to perform all check operations
> depending on the master-detail relation of my snmp tables! And how can a
> manager represent the data in a user friendly report?
>

It could get the INDEX information from the instance suffix portion of the
objects' OIDs. Most NMS do that but there are also some "old-fashioned"
ones...

>
> E.g. I have a 1:n relation between the master and the detail table. If a
> manager perform a table report for the detail table, its very hard to
> identify which rows are related to a specific master row (e.g. HP
OpenView->
> Build SNMP applications -> Table application), since the report don't
> include any index information or oid...
>
> Also is the definition of index objects as "not-accesible" really
mandatory?

No, you may define read-only INDEX objects. Although this is not directly
supported by MIB Designer (because it is discouraged by SMIv2) you can
do it and AGENT++ will support it too.

Best regards,
Frank