nv-l
[Top] [All Lists]

RE: [nv-l] nvtecia still hanging or falling behind processing TEC_ITS.rs

To: nv-l@lists.us.ibm.com
Subject: RE: [nv-l] nvtecia still hanging or falling behind processing TEC_ITS.rs
From: James Shanks <jshanks@us.ibm.com>
Date: Thu, 16 Sep 2004 16:40:25 -0400
Delivery-date: Thu, 16 Sep 2004 21:53:58 +0100
Envelope-to: nv-l-archive@lists.skills-1st.co.uk
In-reply-to: <19CB6EF00D189646B76B570E0301C8BD04D647E2@shcrpx19.wm.com>
Reply-to: nv-l@lists.us.ibm.com
Sender: owner-nv-l@lists.us.ibm.com

So what's different?  Is your wpostemsg to @EventServer like your tecint.conf file?  
We are back to this being a TEC issue and not a NetView one.  So unless you want to open a problem to TEC support, you'll have to do some more detective work yourself.

 If both the wpostemsg and the tecint.conf have @EventServer, then I don't know what to tell you.  If not, then reconfigure your tecint.conf using serversetup to use the non-TME method (which requires that a different daemon be started than when you use the TME method).   For non-TME forwarding, /usr/OV/bin/nvserverd is started.  For TME forwarding, it is /usr/OV/bin/spmsur, who then starts /usr/OV/bin/tme_nvserverd.  To which from one to the other requires that you go through serversetup, which will  reconfigure this automatically, or  that you manually alter the /usr/OV/conf/ovsuf file to start the correct daemons.  But note that when you go through serversetup, your special customization to the Nvserverd entries is lost.  
 

The fact that events are going to the cache means that nvserverd got the event, formatted it, did his tec_put_event( ) and all went fine, but then TEC library code in trying to send to the TEC server found that it could not, that it has lost connection to the TEC server, for some reason known only to those internal routines.  And without a diag (as in "diagnosis") file configured in here so that the internal TEC library code will trace itself, no one can tell you what it's doing or why.  And you have to get that diag file, called ".ed_diag_config" from TEC Support and they are the ones who have to look at the traces.  No one on the NetView side can assist at this point.

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



"Edwards, JT - ESM" <JEdwards3@wm.com>
Sent by: owner-nv-l@lists.us.ibm.com

09/16/2004 04:00 PM
Please respond to
nv-l

To
"'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
cc
Subject
RE: [nv-l] nvtecia still hanging or falling behind processing TEC                                        _ITS.rs





Yes it does.
-----Original Message-----
From:
owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On Behalf Of James Shanks
Sent:
Thursday, September 16, 2004 2:32 PM
To:
nv-l@lists.us.ibm.com
Subject:
RE: [nv-l] nvtecia still hanging or falling behind processing TEC _ITS.rs


Wpostemsg does not go through the internal adapter.  Does that get to the TEC server?


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


"Edwards, JT - ESM" <JEdwards3@wm.com>
Sent by: owner-nv-l@lists.us.ibm.com

09/16/2004 03:17 PM
Please respond to
nv-l


To
"'nv-l@lists.us.ibm.com'" <nv-l@lists.us.ibm.com>
cc
Subject
RE: [nv-l] nvtecia still hanging or falling behind processing TEC                                _ITS.rs







Well at this point. We are now getting events caching. From there what can we do?

 

A wpostemsg does not clear the cache.

 
 

-----Original Message-----
From:
owner-nv-l@lists.us.ibm.com [mailto:owner-nv-l@lists.us.ibm.com]On Behalf Of James Shanks
Sent:
Wednesday, September 15, 2004 10:16 PM
To:
nv-l@lists.us.ibm.com
Subject:
RE: [nv-l] nvtecia still hanging or falling behind processing TEC _ITS.rs

No. The errno 827 indicates that there is a problem initializing the JVM -- Java Virtual Machine. In almost every case I have seen this indicates that the nvserverd daemon does not have the correct library path for Java or the ZCE_CLASSPATH variable is not set. Since it is only set in /etc/netnmrc, if you ovstop all the daemons and restart them with just ovstart, you will lose it. So Mike is right. The usual fix is to ovstop nvsecd and then restart with /etc/netnmrc (/etc/init.d/netnmrc on Solaris or Linux). This issue has been fixed in the upcoming FixPack 2 (FP02) by updating the NVenvironment script so that if you run that before you do ovstart, it will source the correct environment for you, and then the daemons will inherit it when you do the ovtstart.

But I still don't know why you are not getting an nvserverd.log which shows the same tec_create_handle failure that you see in the formatted nettl. We do get that here.

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

<Prev in Thread] Current Thread [Next in Thread>

Archive operated by Skills 1st Ltd

See also: The NetView Web