Nobody asked me, but I'll offer this suggestion anyway. This is a very
good example of what can happen when you get what you wish for. When
I use the location.conf file, very often I make a point of removing it
after
it has done the hard work of setting up all of my location icons and
nesting
them and sticking a few key networks in them. Then I play with the map
for a while to see how I like it. Then I update the location.conf file and
have another go at it - rediscover, or do File..New Map. Then remove
it again. Once I get it the map the way I really want it, I do a full
rediscovery
with the finalized location.conf in place. Then I might leave the there.
Cordially,
Leslie A. Clark
IBM Global Services - Systems Mgmt & Networking
Detroit
"Scott Bursik" <nv_list@hotmail.com>@tkg.com on 04/09/2001 09:13:59 AM
Please respond to IBM NetView Discussion <nv-l@tkg.com>
Sent by: owner-nv-l@tkg.com
To: nv-l@tkg.com
cc:
Subject: [NV-L] Re: location.conf and shadows
I had a PMR with Tivoli for quite some time on this subject (now closed)
and
I have received a couple of e-mails from other folks with the same issues
and I though that I would share the following with everyone. Let me know
your thoughts on the matter.
THIS IS FROM MY PMR:
Problem Details
.
Abstract:
TivWeb: Rediscovery and shadowed objects
.
System Type: 7026-H70
System Model: RS6000
Other related devices:
.
Operating System: AIX 4.3
Product Group: NetView for UNIX
Fileset or Version: 6.0.1
.
Environment:
AIX NetView Server with no MLM/Clients
.
Problem Description:
We had discovered and manually removed objects from the root map to
locations that we had created both manually and with the location.conf
file. Everything was running OK and then I was told that discovery had
stopped. I performed a "resolve database consistencies" from serversetup
and when that was completed I reopened the map. NetView is now
rediscovering the objects I have already placed in other containers and
placing them on the root map. The objects that were already there now
all have shadows. I have DB backups from every day for the last 2 weeks
if that will help. I am not at permanent phone number so e-mail is the
best option today. Thanks.
------------------------------------------------------00/12/01-17:04--CC
------------------------------------------------------00/12/01-17:04--CC
CALL HAS BEEN PORTED INTO TSD FOR PROCESSING BY TIVOLI SUPPORT
TSD2000120111 PROBID143843
------------------------------------------------------00/12/01-20:21--CE
Snet CC the following email:
At this point your best bet may be to go ahead and restore the DB.
That way when the DB maintenance is run again we can capture
the output of the commands to a file so we can see exactly what
they are doing. Another tech here tried it and did see some strange
happenings, but to associate it with PMR we really need to get your
outputs. What commands did you run for the DB maintenance?
Get back with me when you get a chance and let me know if this
will work for you!
Waiting for reply
Waiting for reply to email
------------------------------------------------------00/12/01-20:21--CC
------------------------------------------------------00/12/04-13:54--CE
PMR Completed by Tivoli. Please review.
------------------------------------------------------00/12/04-13:54--CC
------------------------------------------------------00/12/04-13:54--AT
CC restored the DB and did the DB maint again and everything appears OK
this time, CC agreed to close the call and will reopen if neccessary.
Closing per CC, reopen if necc.
------------------------------------------------------00/12/06-20:05--CE
CC requested call be reopened as the problem has resurfaced. CC is
sending in his DB, so we can see what is happening. Checking DB and
researching.
Looking at CC's DB
------------------------------------------------------00/12/06-20:05--CC
------------------------------------------------------00/12/08-13:36--CE
After looking at the CCs DB, I was able to see that the object was in
both locations. It was also the same object
(oid 2792). I was able to recreate it with the following scenario:
Clear the databases and create a location.conf file with a nested
location. Once the map is drawn and the object is properly placed in the
location defined in the location.conf file. In the Upperlevel location,
create another location, and create a location in that location. Then
cut a paste from the its original location and place it in the lowest
level location that was created manually. Wait for the discovery poll(I
had to wait overnight) and the object will reappear in the original
location. Both objects will be in the application plane and point to the
same object in the database.
The database that I created is on support. You will able to see the
object in both locations and the Object information will point to the
same object in the database. I also included the location.conf file I
used to create the original locations in the tar file. APAR needs to be
written. Passing to Roy on the backend.
RK-NEW-12/08/2000-8:30am-APAR needs to be written on location.conf
disocvery
------------------------------------------------------00/12/08-13:36--CC
------------------------------------------------------00/12/12-19:24--CE
CUSTOMER REP: Scott Bursik
ACTION TAKEN: Note sent to L3 asking if apar needs to be written.
ACTION PLAN: WL3(LLi)
RK-12/12/2000-Note sent to L3(LLi) to see if APAR needs to be written on
location.conf disocvery
------------------------------------------------------00/12/12-19:24--CC
------------------------------------------------------00/12/14-18:43--CE
CUSTOMER REP: Scott Bursik
ACTION TAKEN: This is an ipmap problem and should go to L3(FC).
ACTION PLAN: WL3(FC) note sent 12/12.
RK-12/12/2000-Note sent to L3(FC) to see if APAR needs to be written on
location.conf disocvery
------------------------------------------------------00/12/14-18:43--CC
------------------------------------------------------01/01/13-00:31--CE
CUSTOMER REP: Scott Bursik
ACTION TAKEN: Note sent to L3(FC) for status.
ACTION PLAN: WL3(FC) note sent 01/12.
RK-12/12/2000-Note sent to L3(FC) to see if APAR needs to be written on
location.conf disocvery
------------------------------------------------------01/01/13-00:31--CC
------------------------------------------------------01/02/16-15:57--CE
CUSTOMER REP: Scott Bursik
ACTION TAKEN: Note sent to L3(FC) for status.
ACTION PLAN: WL3(FC) note sent 02/16.
RK-02/16/01-Note sent to L3(FC) to see if APAR needs to be written on
location.conf disocvery
------------------------------------------------------01/02/16-15:57--CC
------------------------------------------------------01/02/19-20:57--CE
RK-02/19/01-Note sent to L3(FC) to see if APAR needs to be written on
location.conf disocvery
------------------------------------------------------01/02/19-20:57--CC
------------------------------------------------------01/02/20-22:02--CE
CUSTOMER REP: Scott Bursik
ACTION TAKEN:
Note from L3(FC)
What we have here is a case of duplicatesymbols. Duplicate symbols
are allowed: for example, you may have the same node in multiple
smartsets on a router on two or more submaps. So that is why both
nodes highlight: it is the same object.
.
Since multiple symbols are supported, we can't really change anything
in the way we read the location.conf file. We need to add something
to the ipmap documentation that says that when a node listed in
location.conf is moved, it needs to be removed from the location.conf
file, or the file must be modified to reflect the change.
ACTION PLAN: I called Scott and he said the call can be closed.
RK-02/19/01-Note sent to L3(FC) to see if APAR needs to be written on
location.conf disocvery
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|