Hi James,

I've had this occur before on 6.0.1 when I had a "forward" step in an
ESE.automation rule.  I've since fixed that.

However, you suggesting that Mike check netstat -a for queues of 32K made me
curious.

I've checked mine today and there are lots of 32K in queues (TCP connections
- not sockets).

All my current alerts are being processed, all daemons are OK, and stopping
actionsvr made no difference.

Would this be normal in 6.0.1 or are you suggesting it's not normal in any
version of Netview?

BTW, we have Solaris 2.7.

Thanks,

Peter Anderson
Senior Communications Analyst

Any views or opinions presented are solely those of the author and do
not necessarily represent those of Westpac Banking Corporation.


-----Original Message-----
From: James_Shanks AT tivoli DOT com [mailto:James_Shanks AT tivoli DOT com]
Sent: Wednesday, March 14, 2001 3:12 AM
To: IBM NetView Discussion
Subject: Re: [NV-L] Event processing aborts intermittently



5.1.1 is out of support.  You need to install  5.1.3.

What kind of closer investigation did you do?

Is nvcorrd still running?  How about nvserverd?   Does netstat -a show any
sockets backed up (with values of about 32K in the send and receive
queues)?
If yes, are you running any rulesets in ESE.automation?   If yes, try
"ovstop actionsvr" and see if things get freed up.
Were there any cores (look in /usr/OV/PD/cores)?
If nvcorrd is still running, and you still have no clues from the above,
try running the nvcorrd trace by issuing "nvcdebug -d all" and then looking
at nvcorrd.alog.  Are events still being processed?


James Shanks
Team Leader, Level 3 Support
 Tivoli NetView for UNIX and NT



mike.lang AT barclays.co DOT [email protected] on 03/13/2001 10:56:17 AM

Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>

Sent by:  owner-nv-l AT tkg DOT com


To:   nv-l AT tkg DOT com
cc:
Subject:  [NV-L] Event processing aborts intermittently



Hi all,

Kit - Netview 5.1.1 on Solaris 2.6

Every few days the events display stops, closer investigation reveals
that all ruleset processing has stopped, trapd.log is still updated OK
so it looks like a communication problem between trapd and nvcorrd?

Any ideas?

Cheers,

Mike.







Internet communications are not secure and therefore the Barclays Group
does
not accept legal responsibility for the contents of this message. Any views
or opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.