Sorry, I did not mean to imply that this was due to the Tnm code, but a
difference between the mibs included by default with these versions.
> The mib(n) man page says about MIB node names:
>
> A globally unique name is therefore the combination of the MIB
> module name and the name of a MIB node defined in the module (e.g.
> SNMPv2-MIB!sysDescr).
>
> The only purpose of the SNMPv2-MIB!sysDescr notation is to make the
> descriptor sysDescr unique. You are trying to use this notation as a
> filter mechanism which of course does not work. (Note, the Tnm
> extension does not keep information about multiply defined nodes
> because the SMI forbids all semantic changes to a MIB node once it is
> has been defined.)
>
I didn't realize the oids for system under v1 and v2 mibs were off the same
branch. This, I think, was a mistake by the v2 powers-that-be, but I don't
mean to get started on this.
> One solution to your problem is to remove rfc1907.mib from the list of
> default MIB modules in $tnm(mibs:core) during startup. But anyway, if
> you know that you are only interested in a subset of elements, why
> don't you simply list this subset in your script?
Yes, that would be the right way to go, if I did know which specific MIBs
to include. Unfortunately, I don't. My script is a toolkit that provides
consolidated polling, among other things. Most of the time, my customers will
be using their proprietary mib, but occasionally, you like to poll for things
from mib-2. I do most of my testing with mib-2, and so was a little surprised
by the behaviour. We can certainly work around it by having my customer eliminate
the default MIBs and load the ones of interest in his startup code.
Thanks again for the info and the quick response.
Michele
===============================================================
Michele Chen PQ Technologies, Inc.
michele@pqtech.com (formerly Technology by Design)
WWW: http://www.pqtech.com 3300 Blue Ridge Court
Voice: (805) 497-9321 Thousand Oaks, CA 91362
FAX: (805) 497-9331