Before I say anything else, let me say that your problem(s) sound so
convoluted, what with things working some of the time and not others, that
I think your only hope of resolution is calling Support. Even if I answer
your questions about ipmap as best as I can, that will not bring make
things which are failing work correctly. And I doubt that my answers will
make things any clearer for you. I would also like to point out that I
believe the current level of the Digital product to be 4.1G, so I recommend
that you obtain a more current version and install that.
- what criteria determine whether ipmap will adopt an interface card
created by another application?
I am not sure how to answer this because there are many factors involved.
Generally speaking ipmap does not adopt symbols from other apps. He will
adopt user-created symbols from the GUI provided these are ipmap-capable
and they are be tied to objects in the object database and in the topology
database. These objects would have to be the sorts of things discovered by
netmon, and whose status is updated by netmon. The reason is that ipmap
doesn't decide what to update on a map -- he is told. Either ovw informs
ipmap that a user action has occurred from the GUI or ovtopmd tells him
that a status update has occurred. Nothing else will get his attention.
- under what circumstances will ipmap stop updating the status for a
symbol it previously did handle?
Again, this answer is difficult because ipmap is not making the decision
himself. Assuming
that the map is shared and both it and the symbol are ipmap-capable, it is
a matter of
ipmap waiting for instructions from owv or ovtopmd. If a map update
happens while the
GUI is down, ipmap should take care of that when the map is re-opened. He
asks ovtopmd for
all the changes that have occurred since the last map close time and
performs
synchronization (making the map status match what's in the topology
database).
- is there a way to trace what ipmap is doing?
Yes, but the output is voluminous and difficult to interpret. You would
add a '-t' in
the ipmap registration file and then turn on nettl tracing and logging for
the OVW and
OVEXTERNAL susbsystems. But the nettl logs fill up and roll over pretty
quick so you need
to be watching for whatever you are looking for pretty closely. And this
may not work at
all at some levels of code (I am not up on what changes are in each Digital
build).
Generally Support relies on the trapd.log to find the trap which netmon
sends to alert
ovtopmd that the status has changed as an indication that ipmap has
something to do.
Hope this helps somehow -
James Shanks
Tivoli (NetView for UNIX) L3 Support
huub.van.roosmalen@TIP.NL on 06/25/98 06:24:39 PM
Please respond to NV-L@UCSBVM.UCSB.EDU
To: NV-L@UCSBVM.UCSB.EDU
cc: (bcc: James Shanks)
Subject: What determines whether ipmap updates a symbol?
Hi,
We are currently running NetView 4.1E for DEC UNIX 4.0. We are
experiencing the problem that, seemingly at random, IP-card
symbols are not correctly coloured. This happens even though
netmon does its job properly. When we select Tools-> Display
Object Information..., NetView shows the correct status.
Running ovtopofix solves the problem for some nodes, but not
all. We have tried both creating the IP cards objects through
the API, and letting NetView discover the nodes itself with the
same results. When we examine the object edit dialog, ipmap is
sometimes listed, but also for those nodes the status is not
always updated. Demand polling a node does not help. And yes,
the status source for those symbols is the object status.
I have the following questions:
- what criteria determine whether ipmap will adopt an interface card
created by another application?
- under what circumstances will ipmap stop updating the status for a
symbol it previously did handle?
- is there a way to trace what ipmap is doing?
>From the documentation I have not been able to get a clear answer to
the above questions. Any help would be appreciated.
Huub van Roosmalen
|