Well, that depends on the nature of the problem. You haven't quite told us
the whole story.
You said you used "nvtecia -stop" but didn't mention "nvtecia -reload".
Yet you had to have used that as well if you were expecting a reconnection.
And it is the reconnection that failed, not the stop.
As I already told you, the reason that nvtecia was not working was that the
jar files and the environment are incorrect as a result of TEC library
changes we were forced to incorporate into FP02, and this has been resolved
in FP03. It's all working in the test labs run by our Verification folks
as I write. They are in "long runs" now in preparation for a ship date of
April 1. So yes, I believe that your problem will be resolved with FP03.
In the meantime, FP02 offers you a way to see more closely what nvserverd
is doing with regard to sending events to TEC. We added the keyword
NvserverdTraceTecEvents to the tecint.conf file. It appears automatically
if you regenerate the file using serversetup, but it is commented out. If
you uncomment it and restart nvserverd, then he will begin keeping a log,
/usr/OV/log/nvserverd.log. You'll see nvserverd attempt to create a tec
handle, to connect to nvcorrd with a particular ruleset names, and you'll
see him log every event before he hands it off to the TEC library code.
Very helpful if things seem to be backed up.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
"Delaire,
Patrick"
<delairep@aetna.c To
om> <nv-l@lists.us.ibm.com>
Sent by: cc
owner-nv-l@lists.
us.ibm.com Subject
RE: [nv-l] NVTECIA -STOP
03/15/2005 09:06
AM
Please respond to
nv-l
James,
determination the event window was not processing was done by
checking activity in trapd.log
Which had data that should have been forwarded to TEC but were not
displayed in event window.
Here we display all data that is sent to TEC in the event window.
The event window displayed no activity for approximately 30 mins.
Checked the tec cache member, which had 1538 object waiting to be
transferred to TEC.
Errpt has no indication that nvserverd cored
So, the bottom line here is, that this is a known problem scheduled to
be resolved in FP03?
Thanks Patrick.
-----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, March 14, 2005 8:09 PM
To: nv-l@lists.us.ibm.com
Subject: Re: [nv-l] NVTECIA -STOP
Basically, my advice is to stay away from the nvtecia command until you
have FP03, where all the code involved in the rewrite of it is finally
shipped as one. FP03 is due out April .
If you must have it now, then you will need to obtain the fix for
IY65255, else you will not be able to restart the adapter with nvtecia
-reload.
But I haven't heard of nvserverd failing because of nvtecia -stop
before.
When you say the event window stops processing, how did you determine
that? Did you get a pop-up saying that nvserverd was down? How about a
core of nvserverd (check errpt -- "errpt -a | more")?
I also don't understand why you should have to stop all the daemons. A
simple ovstart nvserverd should do the trick.
James Shanks
Level 3 Support for Tivoli NetView for UNIX and Windows
Tivoli Software / IBM Software Group
-----------------------------------------
This e-mail may contain confidential or privileged information. If you
think you have received this e-mail in error, please advise the sender by
reply e-mail and then delete this e-mail immediately. Thank you. Aetna
|