/usr/OV/service/reset_ci is the answer, as several folks have noted, and it
is documented in the Diagnosis Guide. It is a script so you can see what
it does.
But if you are running NetView V5 or V5.1 then you will also have to
change the IP Address used by the oserv for the Framework, or you will not
have a a working Tivoli desktop (the thing you get when you type "tivoli").
If the only reason you installed the Framework was for NetView, and your
NetView box is also the TMR server and the only managed node in its domain,
then reset_ci will attempt to fix that for you, as well as the NetView
address. But this doesn't always work. If not, then you can try this
command as root:
oserv -k $DBDIR -N ali
Note that since it uses $DBDIR you must have sourced the Tivoli environment
first
(issue . /etc/Tivoli/setup_env.sh and don't forget that leading "dot
space")
If your NetView server is not the TMR server or is part of a larger Tivoli
domain, then you should consult the Framework users guide about what to do,
and typically you must do this BEFORE you change the IP address that the
oserv depends on.
James Shanks
Tivoli (NetView for UNIX) L3 Support
"Ken Garst." <KGarst@GIANTOFMARYLAND.COM> on 03/17/99 12:25:33 PM
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: Re: NETVIEW SERVER IP ADDRESS CHANGE
To change the IP address of the Netview server is easy. On an AIX host,
just use smitty inet and enter the new ip address for the adapter.
However, you must tell Netview about this change by issuing the command
reset_ci, which in turn attaches the new ipaddr=hostname to the maps. If
you are running the Netview client with local maps, you must change the
hostname associated with the local map back to the client's hostname by
issuing the command mapadmin -u <mapname>:<client_hostname> on either the
server or client.
Finally, all devices sending traps to Netview must have the new ipaddress
entered as a trap destination into their snmpd.conf files and their snmpd
daemons refreshed. This is nontrivial. On Bay Networks switches, hubs and
routers, this means rebooting them and loss of communications until the
reboot takes effect.
Good luck!
kg
kgarst@giantofmaryland.com
|