Hi John (and sorry James),
we once had the same problem (Netview V. 5.x running on AIX 4.3.2 with AIX
4.3.2 - clients) and some external AIX-specialist tried to track it down to the
bit's going through the cable...
He told us that -to his opinion- there is a design problem using (FIFO-?) Pipes
via NFS-mounts within Netview and that this won't work correctly. Don't know if
he was right, but we changed to log in to the Server via telnet and redirekt
the X-Display. Causes a lot of memory-usage on the server, but it works better.
We still have the problem from time to time, but it's very hard to track it
down because for opening a case with support you have to recreate the scenario,
which is almost impossible, since the fault occurs only about 4-6 times a year
in our environment. And as long as the map stays green we don't have any
problems....
Not much of a for help you, sorry. But maybe a hint for some of the
developement/test-crew listening here to talk about during coffee-time...
Michael Seibold
Gmünder Ersatzkasse GEK
Germany
(
oh, by the way, just to prevent questions:
Netview V5.1.3 on AIX 4.3.1, only 1 map, no nfs-clients, 100 MBit LAN / fully
switched environment, so it should be no network problem, X-Servers Reflection
and Hummingbird Exceed, running both on WIn98 and WinNT 4.0, Suse Linux 7.2,
AIX 4.3.2, HP/UX 10.20, always the same problem. The map (default) displayed
with these X-Servers is read-only, since read-write is opened on the server
itself, no errors displayed when running ovtopofix etc., no problems with full
filesystems, no problem with nameservers since we use local lookup,
netview-cache is large enough to hold all objects in cache, ..... We just stop
all displays, then netview with "ovstop nvsecd", look that all processes are
down and all sockets cleared in /usr/OV/sockets, and then start over with
/etc/netnmrc - and the problem vanishes for a few months...
we learned to get used with this...
)
>>> SHANKS@us.tivoli.com 09.07.2001 13.16 Uhr >>>
If your client is running a read-only map, which means that one is up on
the server or on another client that has it read-write, then you will see
status chnages but not new additions to the map. This is the limitation of
shared maps and has always been the case. No new items and no alterations
will take place on a read-only map until it is refreshed, only color
chnages due to changing status. This included no new interfaces cards and
no new items in a smartset collection. Sorry to disappoint you but this is
entirely normal.
This is one big reason why many people prefer the web client, since it
continually publishes new copies of the server map all on its own.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
John Mackney <john.mackney@uk.logical.com>@tkg.com on 07/09/2001 05:55:22
AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: "Netview Support list (E-mail)" <nv-l@tkg.com>
cc:
Subject: [NV-L] Client does not reflect Server MAP changes
We have a NetView server (running on SUN Solaris 2.8) and a NetView client
(AIX 4.3.3). The client has the NetView server databases and conf
directories mounted with NFS.
The client only shows the correct state of the NetView Server MAP when a
manual refresh is performed. Shouldn't the client map update automatically.
When we first installed the client, the maps on the client and the server
stayed in synch. We can't explain why it doesn't happen now. We have
severed the client/server link and joined them up again, but it hasn't
helped.
Any suggestions?
John Mackney
Technical Design Authority
Logical eBOC
Logical (UK) Ltd.
Email: john.mackney@uk.logical.com
_________________________________________________________________________
|