nv-l
[Top] [All Lists]

Re: NV Service Point

To: nv-l@lists.tivoli.com
Subject: Re: NV Service Point
From: James Shanks <James_Shanks@TIVOLI.COM>
Date: Mon, 8 Feb 1999 11:38:33 -0500
Reply-to: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
Sender: Discussion of IBM NetView and POLYCENTER Manager on NetView <NV-L@UCSBVM.UCSB.EDU>
I think your customer should open a problem with Tivoli/IBM Support.

How do you measure this delay?  Is it the time difference between how long
it takes to see the event in the event window and on OS/390 NetView NPDA?
Or is it from the trap appearance in trapd.log and OS/390 NPDA?
The question is, is the NetView for AIX event window also troubled by this
delay or not?     If it is, then the problem is almost certainly one of
name resolution.  That means there is a problem with your customer's
nameserver or the way that he has name resolution set up.  If the event
window is not bothered, then you may still have a name resolution problem,
but you will need assistance in determining just where the problem lies.
This will require a call to Support and a Service Point trace.


As for ovesmd and ovelmd, those are the names of the executables, but not
the names of the daemons.  Often they are the same, but in this case they
are not.  The daemon for ovesmd is called the ems_sieve_agent.  The daemon
for ovelmd is called the ems_log_agent.  To control them individually, you
must use their correct names:
      ovstart/ovstop/ovstatus   ems_sieve_agent
      ovstart/ovstop/ovstatus   ems_log_agent
If you just do   ovstatus  | more   you will see the correct name in the
field "object manager name".

All you accomplished with your ovaddobj is to re-register the daemon with
exactly the same characteristics, since the name is specified in the lrf
file that way.

James Shanks
Tivoli (NetView for UNIX) L3 Support



Jens Hahn <hahnj@DE.IBM.COM> on 02/08/99 11:03:47 AM

Please respond to Discussion of IBM NetView and POLYCENTER Manager on
      NetView <NV-L@UCSBVM.ucsb.edu>

To:   NV-L@UCSBVM.ucsb.edu
cc:    (bcc: James Shanks)
Subject:  NV Service Point







Hi all -

I've a problem with the delay of NV or maybe also with the NV Service
Point.

The alerts which NV generates from the traps we forward via the NV Service
Point to the NV OS/390. The problem is, that the alerts comes with a delay
of
an half hour to the NV OS/390. This is not acceptable for us and our
customer.

We are using NV 6000 4.1.2 level U453385 on a RS/6K F50 with 4 processors
166MHz and 2 GB RAM. All processors are 25% idle. Therefore the HW should
not
be the reason for this delay.

Maybe it can be the reason, that we have some trouble with the ovesmd and
ovelmd. Both daemons are running but sometimes they stop and I don't know
why.
If I try to restart the daemons then I get the error message "The Daemons
are
not registered!". If I add the daemons with ovaddobj then I get "Successful
Completion". But if I will restart the daemons with ovstart ovesmd ovelmd
then
I get the same error message as before. Only if I use ovstart then the
daemons
will be started. ?????

Thanks in advance for all hints !!!!

MfG // Best Regards
Jens Hahn
_________________

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

Archive operated by Skills 1st Ltd

See also: The NetView Web