I like your answer Leslie! I have started using it basically the same way
now. I think the documentation needs to be a little more descriptive in this
area so people understand what they are getting into when they choose to use
the location.conf file. Thanks again.
Scott Bursik
>From: "Leslie Clark" <lclark@us.ibm.com>
>Reply-To: IBM NetView Discussion <nv-l@tkg.com>
>To: IBM NetView Discussion <nv-l@tkg.com>
>Subject: Re: [NV-L] Re: location.conf and shadows
>Date: Mon, 9 Apr 2001 23:11:10 -0400
>
>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
>
>
>_________________________________________________________________________
>NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________
|