RE: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

[James Shanks <jshanks@us.ibm.com>]

Well, I'm confused.

You do have to regenerate the tecint.conf
file using smit or serversetup to get the new lines added automatically.


But comments are comments, so I don't
see how adding them would make a difference.  There are already other
commented lines in the tecint.conf, and it doesn't matter whether they
are physically present are not. 

But restarting the nvserverd daemon
might have made a difference.

Please let Support know if this fix
doesn't resolve your problem(s).  

Regards

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

"Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>
Sent by: owner-nv-l@lists.us.ibm.com

08/31/2004 04:09 PM

Please respond to
nv-l

To	<nv-l@lists.us.ibm.com>
cc
Subject	RE: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

I figured your information would
be more thorough. Thank you, that is exactly what I was looking for.
 
What you describe in terms of
the patch changing tecint.conf and having to turn things on sounds like
the desired behavior, only ours did not do this. We suddenly stopped getting
events at the test server and I found tecint.conf unchanged. On a hunch
I decided to manually add the lines after reading the man page, then it
started working. I guess that's what test servers are for..
 
Drew
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of James Shanks
Sent: Tuesday, August 31, 2004 2:34 PM
To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?


Drew - 

Test fixes are cumulative.   
IY60528 is the last fix in a chain.  It supersedes two earlier ones,
IY57383 and IY56279, both of which implement changes to nvserverd and related
code.    So rather than force you to get IY57383 and put it on,
and then IY56279 and put it on, and then apply IY60528, the earlier ones
were removed and only the latest and final one is available.  That's
because once the code is committed, if you have a problem, I can only go
back as far as the last committed level.  So there is no point in
providing a fix I cannot support.   So, unless you'd rather wait for
7.1.4 FP02, IY60528 is what you should put on.  

There was no public APAR for the event hang you have been seeing.  It
was found in Verification and corrected internally, and the first fix to
actually ship it had an internal number, 130890.   That went only
a to a few select customers who reported the same problem before we could
build an official fix.  And since the code for IY57383 was ready at
that time, the internal fix was replaced by IY57383, and but that was soon
superseded by IY56279, and that by IY60528.   

And the readmes for test fixes only describe what that specific fix is
for.  The code is cumulative but the readme text is not.  So
IY60528's readme doesn't mention the earlier problems and enhancements
it also contains.   As for what IY60528 actually adds to nvserverd,
you reading way too much into the description.   IY60528 doesn't force
you to do anything new.  It does put a new entry into the tecint.conf
file, which if you uncomment it, will cause new behavior from nvserverd,
but otherwise not.   IY56279 did the same thing.    All
told, between them there are three new entries in tecint.conf, all of which
are commented out by default, which you can use or not.  And there
is a brand-new, completely-rewritten man page for tecint.conf which explains
what those options do.   But whether you choose to use those new options
or not, you need an nvserverd built with an upgrade TEC EEIF library to
solve the memory leak / hang problem.   

I hope this helps. 
Feel free to ask more questions.    But don't be afraid of putting
on IY60528.  Unless things change in the next 4 weeks, it will be
what we ship in FP02.   
Verification is running with it on their systems right now, dozens of them.
  So you are not the first, and certainly not alone.

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

"Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>
Sent by: owner-nv-l@lists.us.ibm.com

08/31/2004 02:51 PM

Please respond to
nv-l

To	<nv-l@lists.us.ibm.com>
cc
Subject	RE: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

Hope you're out there James-- 
  
I find myself stuck in the middle between what you have stated and what
the current support engineer is telling me. I honestly think what you are
telling me is more accurate, i.e. there is an issue with EEIF and nvserverd
that this efix resolves, even though the abstract for the efix states it
only enables NV by default sending severity info to TEC via tecint.conf
changes. I've asked support for clarification but figure I can get an answer
faster here. 
  
I understand completely if you are uncomfortable commenting on the current
situation; my concern is putting in a pretty big change (if NV severities
are not set and ready to go for ALL traps feeding TEC_ITS you are in for
a surprise as it turns that on and baroc severity slots are ignored. The
abstract does not state that if you don't tweak tecint.conf immediately
events will not make it through TEC) that doesn't address the core issue
of events hanging up in the interface. 
  
Thank you!--Drew 
-----Original Message-----
From: owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]
On Behalf Of James Shanks
Sent: Monday, August 30, 2004 7:40 AM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] 7.1.4 Is the hang in nvtecia or ruleset?


Drew, 

Do you have any post-FixPack1 maintenance applied?  There was a serious
problem with the TEC EEIF library uncovered in Verification after 7.1.4
 FixPack1 went out the door.  It had a memory leak which caused
it to hang after some extended period of time.  TEC has since fixed
the problem.  Every post-7.1.4 FP01 test fix which shipped nvserverd,
and there were several, has the new  TEC EEIF library linked in.  If
you haven't applied anything yet, I would just download the latest and
greatest, IY60528, and install that until FP02 is available at the end
of the quarter. 

Also, I would stay away from using the nvtecia command for the time being,
and just use ovstop/ovstart for nvserverd (Sorry).  The command "nvtecia
-stop" seems to  work OK, but "nvtecia -reload" is
hanging or failing to complete on most platforms.  There seems to
be a re-initialization problem with State Correlation Engine after you
stop it, but don't destroy the process.  I have some TEC guys looking
at that now, so stay tuned. 

HTH 

James Shanks
Level 3 Support  for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group

"Van Order, Drew \(US - Hermitage\)" <dvanorder@deloitte.com>
Sent by: owner-nv-l@lists.us.ibm.com

08/29/2004 09:34 AM

Please respond to
nv-l

To	<nv-l@lists.us.ibm.com>
cc
Subject	[nv-l] 7.1.4 Is the hang in nvtecia or ruleset?

Hi all, 
 
I'm back with another NV to TEC integration question/problem. Everything
is centered around TEC in our organization; everything we tell NV to act
upon is designed to generate a TEC event. We are seeing intermittent delays
in receiving TEC events through our TEC_ITS ruleset. Sometimes it will
resolve itself within an hour, other times a full daemon cycle is needed,
and NV is fine afterwards. The ruleset in use is the core TEC_ITS ruleset
provided with 7.1.4 and we have added 8 trap settings nodes to generate
events from our routers/switches/eventually Compaq Insight Agents. We have
no timer or decision making nodes, it's very basic.
 
The issue appears to be in ruleset processing or TEC forwarding. I say
this because when you ovstop/ovstart, events from the ruleset suddenly
appear at TEC. There are no trap storms occurring when these delays hit.
We are getting ready to manage considerably more devices and will have
to add even more trap nodes to TEC_ITS.rls, so we've got to get a handle
on why this is occurring. Any troubleshooting ideas or places where we
may have a configuration problem? 
 
Thanks much--Drew

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.

This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited.