Maps synchronize every time they are opened. How long they synchronize
depends on how much activity has taken place in since they were last
brought up.
ipmap asks ovtopmd for all changes since the last map close time, which is
recorded in the map database for each map. When you run ovtopofix you may
affect that by changing the last update time for all the objects on the
map, and that's why synchronization takes longer after you use it. But
that is what it is for -- to tell ipmap to re-evaluate what it shows on the
map by affecting what is stored in topology. If the blue objects you
complained about last time are no longer blue, then they should never go
blue again.
It sounds to me like everything you are reporting here is normal behavior,
so I don't understand any more what is the problem you are trying to solve.
Multiple maps are going to cost you more in both administrative time to set
them up and synchronization time when they are brought up.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
z_esm_karekars <z_esm_karekars AT bharatpetroleum DOT com>@tkg.com on 07/10/2001
07:54:30 AM
Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
Sent by: owner-nv-l AT tkg DOT com
To: "'nv-l AT tkg DOT com'" <nv-l AT tkg DOT com>
cc:
Subject: RE: [NV-L] Maps keep on Synchronize
Hi James,
Thanx, James I use small a i.e. ovtopofix -a, and not A. Actually I had
created one main map for central administrator and copied the same map
as other regional administrators and removed unwanted objects. After
this I had done ovtopofix. Will this make difference if I create one map
at each time and do the topofix every time I create the map ?
After the first time synchronization if I close the map next time I open
the same map again it starts synchronization, is it normal or wrong
configuration, if wrong configuration how can I fix it ?
Regarding the Blue objects actually after the synchronization gets over
the status gets updated to normal and colour gets changed to green or
yellow hence it is not cut-paste mistake.
Please advice ASAP.
Regards,
Santosh
----------
From: James Shanks[SMTP:SHANKS AT us.tivoli DOT com]
Reply To: IBM NetView Discussion
Sent: Thursday, July 05, 2001 7:08 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] Maps keep on Synchronize
You can expect slow synchronization of a new map, because
synchronization
is the process whereby the open map is made current by the data from the
topology database. How did you run ovtopofix? With the -a (little a)
option or the -A (big A) option? Once you have more than one map, you
should be running the -a option only, as the man page will tell you,
else
you will bring about the need to update every object on every map, not
just
the ones which have recently changed. In any case, synchronization is
required, and it will be slow at least for the first time for every new
map
you create.
The blue stuff means that somehow in your customization you have made an
error during your cut-and-paste operations. Either you have moved
things
illegally and now the are in the user plane (they will have a shadow
around
them if this is the case) or you have removed some underlying object
whose
status is to be propagated up to give the blue thing (node, segment,
network) its status, and without something below it, it has none of its
own. You will have to look into each case individually and compare
what
is on the default map, which is presumably OK, with what you have on
each
of the new maps, to see what is wrong. This will be a case-by-case
thing.
Perhaps you would be better off by deleting 6 of your seven maps and
starting over, fixing that one, before creating others. I have never
heard
of anyone successfully building seven new maps at one time.
Each map can have a default submap and this is set on a per map basis
from
the GUI. It cannot be different for a different user. I take it that
is
why you decided to create seven maps in the first place, so that each
user
could have his own map. Well, each user can set the default submap (or
you
can do it in each amp before you give it to them) under the File -->
Describe Map function when the map is opened read-write. You cannot
specify it on the startup command.
To set it, each user brings up the map in question "netview -map ABC
-rw"
(note that this is the same command as the archaic "nv6000" which has
been
deprecated and will disappear in some future release, so you should get
in
the habit of using "netview"). Once the map is open read-write by that
user, he can make it his default map (using File --> Open Map) as well
as
set the default home submap (by using File -->Describe Map). Then he
will
just have to type in "netview" next time and he will get the correct
map
opened to the correct submap.
My advice is to pursue your customization in small steps. That way when
you make a mistake, and you will because everyone does, you will not
have
so much to do to recover.
Hope this helps.
James Shanks
Team Leader, Level 3 Support
Tivoli NetView for UNIX and NT
z_esm_karekars <z_esm_karekars AT bharatpetroleum DOT com>@tkg.com on
07/05/2001
03:09:34 AM
Please respond to IBM NetView Discussion <nv-l AT tkg DOT com>
Sent by: owner-nv-l AT tkg DOT com
To: "'nv-l AT tkg DOT com'" <nv-l AT tkg DOT com>
cc:
Subject: [NV-L] Maps keep on Synchronize
Hi,
I had NetView 6.0.1 on AIX 4.3.3 on RS 6000 with 1 GB Memory
I had created 7 maps for different users, after creation of all the map
I
had done topofix. But when ever I start any of the map it keeps on
synchronizing for quite good amount of time and during this
synchronization
the operations over the map goes very slow.
It is also observed that from the customized Maps Router interfaces goes
off and routers become blue, as well as the connections created between
the
object.
Can U advice which configuration I need to check to restore the problem.
Can I keep only one database for all the Maps ?
Can I open Submap with nv6000 command just like we give command to open
map
i.e. nv6000 -map ABC Can this map be replaced by submap option to open a
submap in the default map.
Please reply ASAP this is very critical
Regards,
Santosh
_________________________________________________________________________
NV-L List information and Archives: <http://www.tkg.com/nv-l>
|
