Because we have some heavily customized ruleset processing going on, high
trap rates, and intermittent traps storms, I assumed that there was a better
probability that the problem was related to our environment more than a bug
in the NetView code. Also, we have only recently gotten 5.1.3 installed,
and I knew that support would recommend installing that rather than work on
a problem in 5.1.2.
On the other hand, the problem you described below may be exactly what we
are experiencing. Most, if not all, of the cores we have are related to
those exact symptoms: closing a dynamic window that has two or more
Reset-ON-Match nodes. There may be other causes, but I haven't checked
every core. The impact of the problem is fairly minor to us, and the
workaround is pretty simple and effective, so we haven't pursued it with
Support. I agree with you that we should, but sometimes the practical
supercedes what's "best" or "better".
Thanks for that additional info, though. It could be helpful to us.
Joel A. Gerber - USAA Information Technology Co. - San Antonio, TX
* (210)913-4231 * mailto:Joel.Gerber@USAA.com " http://www.usaa.com
-----Original Message-----
From: James_Shanks@tivoli.com [SMTP:James_Shanks@tivoli.com]
Sent: Friday, November 10, 2000 10:40
To: IBM NetView Discussion
Subject: RE: [NV-L] nvcorrd dies on signal 11
Joel -
Are you opening problems with Support on these? I see no APARs taken for
you regarding cores in nvcorrd.
And you may have had a core in nvcorrd in 5.1.2 and 5.1.3 but it may not be
the same problem by 6.0.1. The same symptom may have radically different
causes. All known cores in 5.1.2 were resolved in 5.1.3, and there were
no new ons reported by the time 5.1.3 shipped. And 6.0.1 is ahead of
5.1.3. I know this because I fixed them. A new APAR was opened yesterday
for a core which occurs when a dynamic window containing a ruleset that
thas two or more Reset-On-Match nodes is closed, but that is first
documented report of an nvcorrd core since 5.1.3 was completed in January.
By "documented" I mean that the person who had it called Support and gave
them the core file, core report, ruleset, and logs to show what was going
on. I don't know how to fix what I don't get doc on .
But your circumvention is a good one while you wait for a fix. Still it
would be better if you also calling Support so we cn get t work on it.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
"Joel A. Gerber" <joel.gerber@usaa.com> on 11/10/2000 11:14:25 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
To: "'IBM NetView Discussion'" <nv-l@tkg.com>
cc: (bcc: James Shanks/Tivoli Systems)
Subject: RE: [NV-L] nvcorrd dies on signal 11
We also have the same problem with nvcorrd on both NetView 5.1.2 and 5.1.3.
We're still testing 6.0.1, so I'm not sure we still have the problem in
that
version. I can't offer any help with the root cause or a fix, but if
you're
interested I can send you a script that will monitor nvcorrd, and restart
it. We run the script out of root's crontab every minute. It checks if
nvcorrd is running. If it's not, then it stops the actionsvr daemon, and
restarts them both.
Joel A. Gerber - USAA Information Technology Co. - San Antonio, TX
* (210)913-4231 * mailto:Joel.Gerber@USAA.com " http://www.usaa.com
-----Original Message-----
From: Gruner Mike [SMTP:mike.gruner@rfv.sfa.se]
Sent: Friday, November 10, 2000 01:14
To: nv-l@tkg.com
Subject: [NV-L] nvcorrd dies on signal 11
Have NetView V6.0.1 and Aix 4.3.3 and have a "little" problem with nvcorrd
which
dies on us randomly with signal 11. We have rulesets which we are using for
correlation
and a script which takes away some traps ( eg ISDN BRI ). Has someone
experienced
the same problems as we have ? Any suggestions appreciated ....
Mike Gruner
RFV Sweden
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|