Kuffer Andreas wrote:
> Dear all
>
> To summarize the ideas till now...
> - mksysb / sysback
> - tar (online or offline)
> - /usr/OV/install/tools/nvp.v5r1
>
> Still I do see the problem, that the last EUI-settings will be lost.
> Does anyone know, how to restart NetView-GUI on a PC-box running
> XWinPro (of course in the right CDE-Window with the right maps and
> workspaces open ...)
Do you mean that you want to restart all the GUI's that were stopped? I
wrote a utility for a customer to do that:
1. Stop all read/write EUI's on all clients.
2. Stop all daemons and programs that update the database.
3. Backup /usr/OV/databases.
4. Restart all stopped daemons.
5. Restart all stopped EUIs on the original DISPLAY with the original
User ID with the original map and the original RW status.
I have not been able to bring up the EUI at the spot is was at before it
was stopped though. In other words, the EUI will be up but with if the
user was in some submap when it went down, but it will come up on his
screen with the default submap view that is set up for the particular
map. I am not sure if that can be done. If anyone knows how, I would
love to know!
I don't think I can supply the scripts used to do this without the
customer's permission, but I can tell you how it can be done:
It requires rsh permissions from the NetView server to the NetView
clients.
You will need to identify any maps running on the clients. Gather the
user id, the map name, the status of the map (Read Write or Read Only),
the process ID of the ovw_binary process, and the DISPLAY variable of
the processes environment.
1. To Identify the active clients you do:
To Identify the PIDs of the map's running on the clients, you
can issue this command from the server:
"/usr/OV/bin/nv6000_server showactiveclient
The problem I had with this was that it gave me different
names for the same client sometimes (because we had several
interfaces on the clients and servers and had to set up static
routes since the hostname was associated with an interface
that some clients could not use to access the server). So I
just did an "rsh $client hostname" for each client and then
piped the output of all the names to sort -u
2. To get the userid, and PID of the maps running on each
client, rsh to each client and do this:
ps -eo user,pid,comm | grep -w ovw_binary | while read USER
PID
3. To get the DISPLAY variable, process the output of "ps
aexww $PID"
4. To get the map name, you need to examine each of files
that are expanded by the shell in
/usr/OV/databases/openview/mapdb/*/current/objinfo.pag and do
an "fuser" of them. The fuser command will return the
PID that has the map open where MAP is:
/usr/OV/databases/openview/mapdb/MAP/current/objinfo.pag. So
when you find the map name for which fuser returns a PID that
you have for that ovw_bvinary process, that process has that
map open. There is one PID for each MAP that is open. There
will be only one PID returned by the fuser command for each
file expanded by the shell with:
/usr/OV/databases/openview/mapdb/*/current/map.lock. This is
the PID for the process that has the map open read/write.
Now you should have:
* A list of active clients
* A list of the maps running, and for each map process
running:
o The PID, DISPLAY, USERID, STATUS (Read Only or Read
Write), CLIENT, and MAPNAME.
5. So you save that info, and stop any map that is read write
by sending a kill -3 to the PID on that CLIENT. It may take a
minute or two do stop, that is OK, just wait.
6. Then stop snmpCollect, netmon, and ovtopmd (actually
stopping ovtopmd will also stop netmon and snmpCollect). Run
nvwebstop as well.
7. Backup your data however you want ( I used tar to backup,
and pax to restore (because of sparse files).
8. Restart the stopped daemons: ovstart.
9. Restart any read/write maps you stopped. You need to use
the info you saved in step 5, and start the netview process by
using an rsh command. I use this command:
rsh $CLIENT -n "su - $USER -c \"echo \\\"DISPLAY=$DSP nv6000 $MAPOPTS\\\"
| at now \""
These commands work with AIX, I haven't tried them on another UNIX, and
they are guaranteed NOT to work on NT.
--
Ray Schafer | schafer@tkg.com
The Kernel Group | Distributed Systems Management
http://www.tkg.com
|