Cutting or copying from smartsets Was: TME10 - Cluttered M ap

["Cowan, Chris" <Chris.Cowan@2ndwaveinc.com>]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

There must be some disturbance in the force, because myself and a coworker
were just banging our heads on this very problem, when we saw the posts.

Just a few caveats, the present 6.0.2 location.conf is restricted to 1000
entries.   There is an efix available, and according to the support the
scheme will change again with NV 7.x.

Now my question.

Our location mapping is not just based on IP address.   We were however,
able to obtain a database listing that allowed use to assign extra fields
using nvdbimport, to our objects for book-keeping.

I can build a smart set based on the the new fields.  However, I'm worried
about cutting (actually copying) and pasting from a smart set back into the
IP maps.   Is this a good idea.  

In the past, I remember some caveats about copying vs. cutting and losing
status reporting.

Any advice or recommendations would be appreciated.

Chris Cowan


 

-----Original Message-----
From: Allison, Jason (JALLISON)
To: 'IBM NetView Discussion'
Sent: 6/14/01 7:40 AM
Subject: RE: [NV-L] TME10 - Cluttered Map

Leslie,

Thanks for the response, this sounds like the direction I want to go.  I
am
sure I will have plenty of questions, but you have given me the directed
push I needed.

More to come,
Thanks,
Jason

-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Wednesday, June 13, 2001 11:17 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] TME10 - Cluttered Map


Some of us really enjoy the cutting and pasting. You get faster after
the first few rounds. And if this is a one - or - two map shop, it
really
is not a big deal. Or is there more to it than that? Many operators with
their own customized maps? You might have some work then.

Cluttered is 3000 routers in a big black ball. What you have is
your basic messy map. Here's what I would do ( one day's work):
First, remember all you really have to deal with are routers and
networks. Everything else is below the subnet level, so you don't
have to arrange them (unless you have some wierd stuff).
- Make a location.conf file with ONLY placeholder (0) networks in it.
- Define all of your locations, and the nested sublocations under them.
- Do 'File...New Map'. There is no discovery involved, just a new map
that has all of those icons predefined. At this point you can remove
or rename that location.conf file, allowing you to change your mind,
delete icons, etc,
- Then make a SmartSet (Collection) where isLocation is true.
- Open another window of those, sorted by label, so you can
get at them easily.
- While on the IP Internet submap, cut (from THIS submap) and paste into
the locations, disregarding the heirarchy. This works, believe me.
- Make good use of the Locate function to get things highlighted, making
them easier to spot. Try also View..Highlights...Select Highlights.

Once the new map (eg TEST1) is in good shape, you can delete the
default map and use 'File..Save Map As' to replace the default. Then
open the default and delete the test map, so you are back to one map.

This is not hard. Finding a good layout is harder. If you are
looking for advice on that, ask again. I have opinions on that, too.

Cordially,

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

"Les Dickert" <lesdickert@HOTMAIL.COM>@tkg.com on 06/13/2001 09:30:00 PM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com


To:   nv-l@tkg.com
cc:
Subject:  Re: [NV-L] TME10 - Cluttered Map



Well, the location.conf file is the way
to do, but you will have to be at at least
Version 6.0 to do it, and while you're at
it, you may as well go all the way to
6.0.2.  If you have a support contract
the upgrade is free for the asking from
your account rep.

You say no major design changes (such as
an upgrade to 6.0.2) will be welcomed, but
in the same breath you say you're going to
keep it running for 2 years.  If that's the
case (keeping it running for 2 years), it
is well worth the effort to:

1.  Upgrade to 6.0.2
2.  Create a new seedfile and location.conf
3.  Wipe out your database and let NetView
    re-discover the entire network.

You will really like the appearance of your map
with the locations on it, and a little bit of
manual moving around of things will make it
beautiful (this is the voice of experience speaking).

You'll probably get a standing ovation as did I.

Les Dickert
Verisign Consulting



>From: "Allison, Jason (JALLISON)" <JALLISON@arinc.com>
>Reply-To: IBM NetView Discussion <nv-l@tkg.com>
>To: "'nv-l@tkg.com'" <nv-l@tkg.com>
>Subject: [NV-L] TME10 - Cluttered Map
>Date: Wed, 13 Jun 2001 17:07:13 -0400
>
>List:
>
>My new task is "reducing the number icons in the Netview Map."  I
believe
>we
>are running Netview 5.1.3, I am new to this project (and company).  My
>background is in using Netviews robust API to integrate SNMP Management
>into
>real-time systems, i.e. most of this front-end desktop work is new to
me.
>
>Background -
>Our displays have ~400 subnets (quite cluttered) which include many end
>stations per subnet.  As a note, this is a VERY stable base-lined cash
cow
>product that is being phased out over the next 2 years, no major design
>changes will be greeted nicely.  I have been searching the archived
lists
>and have come across two possible solutions.  I wanted to discuss these
>with
>the list to see what I am missing as well as determine "best practice"
>approaches.
>
>Solutions:
>1.  (Easiest, most operator work) - Manually creating multiple
containers
>in
>some sort of hierarchical approach to "tree" all of the end systems.
Then,
>cutting and pasting objects in and out of the old to new containers.
At
>work we have proven this is a workable solution.  Coming from a
software
>background, I don't believe this is the best solution.  It does not
scale,
>and once this paradigm is set, re-design or re-work is exponentially
>costly.
>Also, this solution has more potential for operator error.
>
>2.  Create a location.conf file of the desirable map layout.  I am not
sure
>if this is even possible.  From what I have read, one needs to have
their
>map all set up, then create a location.conf file from their database,
which
>can be used for restoring the map, etc.  With that said, it seems to me
>that
>it could be generated, am I wrong?  What is the best approach for this?
>
>3. ??  What are your thoughts?  Have any of you worked though this
problem
>yourselves?
>
>Thanks for the help,
>Jason
>_______________________________________________________________________
__
>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

There must be some disturbance in the force, because myself and a coworker were just banging our heads on this very problem, when we saw the posts.

Just a few caveats, the present 6.0.2 location.conf is restricted to 1000 entries.   There is an efix available, and according to the support the scheme will change again with NV 7.x.

Now my question.

Our location mapping is not just based on IP address.   We were however, able to obtain a database listing that allowed use to assign extra fields using nvdbimport, to our objects for book-keeping.

I can build a smart set based on the the new fields.  However, I'm worried about cutting (actually copying) and pasting from a smart set back into the IP maps.   Is this a good idea. 

In the past, I remember some caveats about copying vs. cutting and losing status reporting.

Any advice or recommendations would be appreciated.

Chris Cowan

 

-----Original Message-----
From: Allison, Jason (JALLISON)
To: 'IBM NetView Discussion'
Sent: 6/14/01 7:40 AM
Subject: RE: [NV-L] TME10 - Cluttered Map

Leslie,

Thanks for the response, this sounds like the direction I want to go.  I
am
sure I will have plenty of questions, but you have given me the directed
push I needed.

More to come,
Thanks,
Jason

-----Original Message-----
From: Leslie Clark [mailto:lclark@us.ibm.com]
Sent: Wednesday, June 13, 2001 11:17 PM
To: IBM NetView Discussion
Subject: Re: [NV-L] TME10 - Cluttered Map

Some of us really enjoy the cutting and pasting. You get faster after
the first few rounds. And if this is a one - or - two map shop, it
really
is not a big deal. Or is there more to it than that? Many operators with
their own customized maps? You might have some work then.

Cluttered is 3000 routers in a big black ball. What you have is
your basic messy map. Here's what I would do ( one day's work):
First, remember all you really have to deal with are routers and
networks. Everything else is below the subnet level, so you don't
have to arrange them (unless you have some wierd stuff).
- Make a location.conf file with ONLY placeholder (0) networks in it.
- Define all of your locations, and the nested sublocations under them.
- Do 'File...New Map'. There is no discovery involved, just a new map
that has all of those icons predefined. At this point you can remove
or rename that location.conf file, allowing you to change your mind,
delete icons, etc,
- Then make a SmartSet (Collection) where isLocation is true.
- Open another window of those, sorted by label, so you can
get at them easily.
- While on the IP Internet submap, cut (from THIS submap) and paste into
the locations, disregarding the heirarchy. This works, believe me.
- Make good use of the Locate function to get things highlighted, making
them easier to spot. Try also View..Highlights...Select Highlights.

Once the new map (eg TEST1) is in good shape, you can delete the
default map and use 'File..Save Map As' to replace the default. Then
open the default and delete the test map, so you are back to one map.

This is not hard. Finding a good layout is harder. If you are
looking for advice on that, ask again. I have opinions on that, too.

Cordially,

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

"Les Dickert" <lesdickert@HOTMAIL.COM>@tkg.com on 06/13/2001 09:30:00 PM

Please respond to IBM NetView Discussion <nv-l@tkg.com>

Sent by:  owner-nv-l@tkg.com

To:   nv-l@tkg.com
cc:
Subject:  Re: [NV-L] TME10 - Cluttered Map

Well, the location.conf file is the way
to do, but you will have to be at at least
Version 6.0 to do it, and while you're at
it, you may as well go all the way to
6.0.2.  If you have a support contract
the upgrade is free for the asking from
your account rep.

You say no major design changes (such as
an upgrade to 6.0.2) will be welcomed, but
in the same breath you say you're going to
keep it running for 2 years.  If that's the
case (keeping it running for 2 years), it
is well worth the effort to:

1.  Upgrade to 6.0.2
2.  Create a new seedfile and location.conf
3.  Wipe out your database and let NetView
    re-discover the entire network.

You will really like the appearance of your map
with the locations on it, and a little bit of
manual moving around of things will make it
beautiful (this is the voice of experience speaking).

You'll probably get a standing ovation as did I.

Les Dickert
Verisign Consulting

>From: "Allison, Jason (JALLISON)" <JALLISON@arinc.com>
>Reply-To: IBM NetView Discussion <nv-l@tkg.com>
>To: "'nv-l@tkg.com'" <nv-l@tkg.com>
>Subject: [NV-L] TME10 - Cluttered Map
>Date: Wed, 13 Jun 2001 17:07:13 -0400
>
>List:
>
>My new task is "reducing the number icons in the Netview Map."  I
believe
>we
>are running Netview 5.1.3, I am new to this project (and company).  My
>background is in using Netviews robust API to integrate SNMP Management
>into
>real-time systems, i.e. most of this front-end desktop work is new to
me.
>
>Background -
>Our displays have ~400 subnets (quite cluttered) which include many end
>stations per subnet.  As a note, this is a VERY stable base-lined cash
cow
>product that is being phased out over the next 2 years, no major design
>changes will be greeted nicely.  I have been searching the archived
lists
>and have come across two possible solutions.  I wanted to discuss these
>with
>the list to see what I am missing as well as determine "best practice"
>approaches.
>
>Solutions:
>1.  (Easiest, most operator work) - Manually creating multiple
containers
>in
>some sort of hierarchical approach to "tree" all of the end systems.
Then,
>cutting and pasting objects in and out of the old to new containers.
At
>work we have proven this is a workable solution.  Coming from a
software
>background, I don't believe this is the best solution.  It does not
scale,
>and once this paradigm is set, re-design or re-work is exponentially
>costly.
>Also, this solution has more potential for operator error.
>
>2.  Create a location.conf file of the desirable map layout.  I am not
sure
>if this is even possible.  From what I have read, one needs to have
their
>map all set up, then create a location.conf file from their database,
which
>can be used for restoring the map, etc.  With that said, it seems to me
>that
>it could be generated, am I wrong?  What is the best approach for this?
>
>3. ??  What are your thoughts?  Have any of you worked though this
problem
>yourselves?
>
>Thanks for the help,
>Jason
>_______________________________________________________________________
__
>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