On Fri, 2005-04-08 at 04:08, Jim Su wrote:
> [A]
> moduleType.1001 [integer] controller
> moduleType.3001 [integer] collector
>
> ...
> [B]
> Currently my agent return the values as -
> moduleType.1 [integer] controller
> moduleType.1 [integer] collector
The same index for both? That looks wrong.
If you're using "header_simple_table( ...., 2)"
then you ought to be seeing something like:
moduleType.1 [integer] controller
moduleType.2 [integer] collector
> I tried to do the following in my code hoping to see some output like [A] in
> the above -
>
> case moduleType:
> If (( index == 1 ) || (index == controller_id))
> {
> Name[ *length -1] = controller_id;
> long_ret = 1; // controller) .....}
No - you can't just tweak things in a single object block.
If you're going to start fiddling with the index values, then you need
to do this for *all* objects. The same index value has got to be used
across the whole row.
> I realized it's invalid to modify the instance number for the return
> value - perhaps only 1 and 2 are valid index.
No - you can use whatever index values you like.
The simple table coding assumes they're consecutive,
but that's not compulsory.
> In the header_simple_table I specified the MAX_VALID_INDEX (the last
> parameter) to 2.
> I guess I can change MAX_VALID_INDEX to a larger number (said 4000) - even
> the row
> number is only 2. Can I do that?
Yes - you can specify whatever the highest index value currently is.
But you'll then have to detect (and handle) the missing indexes.
See the code fragment I send you last week.
> I guess I still can do it with header_simple_table. But it looks
> a little bit odd to give a big range of MAX_VALID_INDEX (for only two
> row). Is there a smarter way to do it?
Yes - if there were only a few missing rows in a mostly-consecutive
list of indexes, then the approach I mentioned last week would be
sensible. In this case, with massively-sparse indexing, I'd probably
write an equivalent header routine, dedicated to this particular table,
and working with the known index values.
(Though actually I'd probably use the newer v5 APIs instead).
> [Question # 1]
> How to append the result from one table item to another table item
> as the instance index ? Is this valid? If it is valid what is the clean way
> to do it?
Sorry - don't understand the question.
> Luckily the number of instance (row # of the table is fixed. In this
> case it's 2) so the value was easily returned in between two index number.
Will it *always* be two rows, or might this agent need to work with
three or four rows (perhaps if extra hardware was added)?
Are the index values fixed, or might they change too?
> [Question # 2]
> What if the row # is not fixed and only known from the polling from
> a text (created by other process) or another resource (share memory,
> command line, etc.)? I think the header_simple_table() still can
> handle that according to the definition of simple table.
Correct.
The header_simple_table() approach can be used for such "temporarily
fixed" tables. All that's required is that *at the time it is
called*, the largest index value is known.
> The index is within some range, the index is integer, etc.
> Under this situation (a max number is given during run time)
> how the var_xxxtable() determine what value (among the
> collected data from some where out side agent) to return?
Do you mean how does it know what the largest index value is?
That's up to your code to provide. The Net-SNMP template code
doesn't care how you find this out - all it's bothered about
is knowing what the valid index values are.
If you mean how does the code following know which row to work with,
I've already told you that. That's the purpose of extracting the
index value from the 'name' parameter.
When the 'header_simple_table' call returns, the 'name' field
contains the OID to return a value for, which includes the
index value of the relevant row.
Once again, it's up to your code to extract this index,
retrieve the appropriate data for that row, and supply the
relevant column value from that row.
Dave
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
