Thanks everyone for your help, but I prefer not to delete the location.conf
file yet,
because my network hasn't been completely discovered :
we're installing a whole new network with more than 1000 routers, but this is
taking a couple of months.
So if I would delete the file now, the networks that will be installled later,
won't be put in the right location.
And I can't wait till all the routers are there, because the network operators
have to be able to follow up the routers that have already been installed.
So I start cutting the routers on the RootMap and put them in the right
locations to get a nice map, and then all of a sudden I start getting these
shadows (user plane) again.
Any suggestions ?
Kind regards,
Helen
luigino.perazzolo%telecomitalia.it@Internet
11/04/2001 15:40
To: nv-l%tkg.com@Internet
cc: (bcc: Helen Cloostermans/GKBCCB)
Subject: Re: [NV-L] Re: location.conf and shadows
Hello Helen, I am Luigino Perazzolo and i work in Telecom Italia , i had your
similar problem. My Netview version
is 6.0.1 on O.S. AIX 4.3 (CiscoWorks 2000 integrated) . I work with a very big
network (about one Thousand
routers), and i use the Location.conf file . I tried to cut and paste some
routers from a root map to another ,
but sometimes i did'nt see some objects on destination map . I did'nt loose the
objects because i found them in
the netview databases (i saw the objects with the command ovtopofix). I think
that the resolution is :
a) You can use the location.conf only the first time that you discover the
network.
b) You MUST rename or delete the location.conf file.
c) Now you can cut and paste the object that you want.
n.b. Location.conf is useful only the first time and for eventualy backups
!!!!!!!!!!!!!!
Cordially, take care.
Luigino
Helen Cloostermans wrote:
> Leslie,
>
> My current version of Netview is 6.01. And there are no error messages in the
> location.log file.
> So I 'll have to call support as you suggested.
>
> Thanks,
> Helen
>
> ---------------------- Forwarded by Helen Cloostermans/GKBCCB on 11/04/2001
> 08:16 ---------------------------
>
> lclark%us.ibm.com@Internet
> 11/04/2001 06:11
> To: nv-l%tkg.com@Internet
> cc: (bcc: Helen Cloostermans/GKBCCB)
>
> Subject: Re: [NV-L] Re: location.conf and shadows
>
> Helen, what version are you running? When the location.conf file was
> first introduced (6.0) there was a bug that made it so that you could not
> really cut and paste anything until you had first done an ovtopofix, or you
> would have that problem. That was fixed in 6.01. I hope that you are on
> 6.0, because that would be a reasonable explanation of your problem.
> Otherwise, I think you need to call support because that sounds like
> a different problem. Oh -also check the location log file in /usr/OV/log.
> Perhaps there is some subtle error in the location.conf file. Other than
> that, I don't know.
>
> Cordially,
>
> Leslie A. Clark
> IBM Global Services - Systems Mgmt & Networking
> Detroit
>
> Helen Cloostermans <Helen.Cloostermans@dexia.be>@tkg.com on 04/10/2001
> 09:42:13 AM
>
> Please respond to IBM NetView Discussion <nv-l@tkg.com>
>
> Sent by: owner-nv-l@tkg.com
>
> To: nv-l <nv-l@tkg.com>
> cc:
> Subject: Re: [NV-L] Re: location.conf and shadows
>
> Hello,
>
> If I would cut an object that was in the location.conf file and paste it
> somewhere else,
> I could understand that this might create shadowed objects (user plane).
>
> But I have the problem with routers that are NOT in the location.conf file.
> I don't understand : at first everything works fine, I cut the routers and
> paste them in the appropriate locations.
> And then it goes wrong for every router.
> I tried ovtopofix, but that didn't help.
> Then I did a "Restart automatic map generation" and everything was OK at
> first, but at a certain time, the problem reappeared.
> This is not normal behaviour, is it ?
>
> Thanks,
> Helen
>
> ---------------------- Forwarded by Helen Cloostermans/GKBCCB on 10/04/2001
> 15:18 ---------------------------
>
> nv_list%hotmail.com@Internet
> 10/04/2001 15:14
> To: nv-l%tkg.com@Internet
> cc: (bcc: Helen Cloostermans/GKBCCB)
>
> Subject: Re: [NV-L] Re: location.conf and shadows
>
> 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
>
> _________________________________________________________________
> 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
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
>
> _________________________________________________________________________
> NV-L List information and Archives: http://www.tkg.com/nv-l
_________________________________________________________________________
NV-L List information and Archives: http://www.tkg.com/nv-l
|