It was pointed out to me that I need to clarify this posting a bit. It is not a
Locate field by itself that causes the problem, but rather when it is combined
with the "Name" field, so that each object gets a new unique field by which it
can be located. These NetView has heartburn removing because someone else put
them there and the combination marks them as very important in the database --
they all get linked together.
Note that when I said "ovtopofix" I meant "ovtopofix -a" or "ovtopofix -A" as
appropriate (Capital "A" for more than one map).
It should not be necessary to use the undocumented, very messy and dangerous
"ovtopofix -r" (as was suggested by someone else) to remove an object from the
topology database just because it says "REMOVED" in the object database.
I won't say that it never is, just that it should not. I would never do
ovtopofix -r unless I had a good backup of the whole NetView
/usr/OV/databases/openview directory and was willing to restore it, or scratch
the whole thing and start over.
James Shanks
Tivoli (NetView for UNIX) L3 Support
Art -
If all you changed was the hostname, then demand poll should fix that. It
always has for me provided the new name is the one returned by name resolution
so I don't know why it did not work in your case.
But when an objects says "Removed" it means that it was deleted from the GUI but
that it has some non-NetView fields added to it, which have not been removed.
Usually these are added by a third-party app and to remove them you need to
follow that third party's removal procedure first. Does that apply here? You
can also create this situation with nvdbimport. Unfortunately once a "Locate"
capability field is added to an object, there is no simple way to remove it, and
if you want to override the restrictions, then ovtopofix is your only choice.
James Shanks
Tivoli (NetView for UNIX) L3 Support
|