nv-l

Re:Keeping NV fields up-to-date

2000-04-07 09:10:47
Subject: Re:Keeping NV fields up-to-date
From: lclark AT us.ibm DOT com
To: nv-l AT lists.tivoli DOT com
Date: Fri, 7 Apr 2000 09:10:47 -0400

Joe, most of my work is with new installs, so I don't often see the
kinds of administrative problems long-running installations have.
But here's my two cents' worth anyway.

I believe that the vendor and agent fields do not get updated on a
config poll, only at initial discovery. Those are the only ones that
have bothered me, anyway.

I always make sure that the oid_to_type file is backed up by the
vendor list (ovw_fields) and agent list (snmp_fields). This is not
always done if third-party products are added. If they don't match
exactly, the agent and vendor fields in the oid_to_type file won't
be added to the object info for a newly discovered node.

Then I always set up a collection (smartset) with the criteria of the
vendor field being unset, but which is snmp-capable. This gives me
a group to watch. Anything that shows up in here is probably not drawn
properly, since I know there is no entry in the oid_to_type file for it,
or it was discovered before I updated the configuration files. It flags
new types of devices based on oid. If something shows up, I know
that I have to update the vendor and agent lists, the oid_to_type, and
maybe the oid_to_sym files, and then I delete and rediscover those
nodes, primarily because I want the vendor field to be set, because it
is the criteria for my 'to-do' collection.

Can  you point out other fields that are bothering you?  This discussion,
like the recent discussion of long-term administration of seedfiles, is
one that is best held between customers who see the real-life issues
over the long haul.

Cordially,

Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit

---------------------- Forwarded by Leslie Clark/Southfield/IBM on
04/07/2000 08:54 AM ---------------------------

"Prokott, Joe" <Joe.Prokott AT westgroup DOT com>@tkg.com on 04/06/2000 06:23:27
PM

Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>

Sent by:  owner-nv-l AT tkg DOT com


To:   "'NV Forum'" <nv-l AT tkg DOT com>
cc:
Subject:  [NV-L] Keeping NV fields up-to-date



We have a never ending and growing NetView environment and sometimes
struggle keeping all the NV fields for objects up-to-date.

Does anyone know of a good way to verify that all NetView fields are
up-to-date?  I know there are some NV fields that only get defined upon
initial discovery and will not change unless rediscovered, even if the
fields files themselves have been updated.  Is there a list of these type
of
fields that do not change once initially defined?  Better yet, is there
some
way I can run a script that will either (1) let me know what nodes need to
be re-discovered because there is a conflict with what is defined in the NV
database and what is defined in the fields/oid_to_sym/oid_to_type/etc...
files, or (2) dynamically update these differences to match what is
defined.


There are always new fields added to new versions of NetView and I am never
quite sure if these will automatically be added or if I will need to
rediscover the node so the new fields get added.  It would be nice if
NetView could tell me what the differences were so we could keep things
up-to-date.  It is not practical for us to rediscover our entire network on
some regular basis because we do not know if there are NV object field
changes or not.

I assume many others have this same problem.  I would like as close to an
automated solution to this problem as possible.


Joe Prokott
Network Architect
West Group
phone:  651-687-4536
e-mail: joe.prokott AT westgroup DOT com



_________________________________________________________________________

NV-L List information (unsubscribing, policies, posting, digest version,
searchable archives): http://www.tkg.com/nv-l