Well, Chris, you cannot see it but there are dozens of error messages in
xnmloadmib and xnmloadmib2 but they will never see
the light of day if the code loops trying to read your database. A loop is a
loop is a loop, and by definition if you could
break out of it, you wouldn't be looping. That's what I fixed (or at least
tried to) in the fix I referred to. So unless
you get the latest level and re-create your hosed database, we will never know
if my latest attempt to keep this from
happening was successful or not. That is why I advised you to get it.
I think parsers that loop and don't give you messages are bad too
Tivoli (NetView for UNIX) L3 Support
Chris Cowan <chris.cowan@2ND-WAVE.COM> on 06/21/99 11:25:46 AM
Please respond to Discussion of IBM NetView and POLYCENTER Manager on NetView
cc: (bcc: James Shanks/Tivoli Systems)
Subject: Re: Loading a MIB takes excessive machine resources
James Shanks wrote:
> Are you at 5.1.1? If not, then you should get there. We fixed a problem
> just like that earlier. If you are at 5.1.1 then call Support
> James Shanks
> Tivoli (NetView for UNIX) L3 Support
> Chris Cowan <chris.cowan@2ND-WAVE.COM> on 06/16/99 12:07:51 PM
> Please respond to Discussion of IBM NetView and POLYCENTER Manager on
> NetView <NV-L@UCSBVM.UCSB.EDU>
> To: NV-L@UCSBVM.UCSB.EDU
> cc: (bcc: James Shanks/Tivoli Systems)
> Subject: Loading a MIB takes excessive machine resources
> I am at a customer with a considerable number of HACMP clusters.
> Yesterday, I attempted to load the HA MIB (hacmp.my) into Netview.
> Also, ran mib2trap to generate the trap definitions.
> Anyway, the file is only 29K in size. I have not been able to
> successfully load it yet, because I haven't been patient enough o wait
> for it to finish. So far, it has run over 30 minutes and is steadily
> consuming 98.5% of the CPU. This is on an H50 with 512MB/1GB
> real/virtual memory.
> Needless to say, I'm suspicious that something is wrong. BTW,
> xnmloadmib has been completely quiet, so far. No errors or warnings,
> what so ever.
What was wrong.
Basically, my MIB DB was hosed because of some Cisco MIBs that had been
loaded. Rebuilding the DB solved the problem. That and restricting
ourselves to only the V2 to V1 (converted) MIBs from Cisco.
I have two gripes though:
1. The xnmloadmib util should be a little more verbose. Right now, it
tells you almost nothing. Parsers that don't at least indicate status
are bad IMHO.
2. I really wish that the group was still had the practice of "testing"
3rd Party MIBs with the NV product, like they used to. (Particularly,
for Cisco given it's Market share!)
Description: Binary data