[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

2901.0. "LAN Autotopology....comments" by FOUR62::LICAUSE (Al Licause (338-5661)) Thu Apr 30 1992 13:07

A few comments on the LAN autotopology utility if you wouldn' mind.

1:
When the map is drawn, each icon and its corresponding identifier lable are
drawn a bit too close together.  The only thing that shows where one lable
stops and the other starts is the period.  A bit broader spacing would help.



2: 
The root bridge appears to be identified not only by its address and the fact
that it is the root, but it's type is identified and the appropriate icon
drawn.  Is it possible within this utility, to further identify the other
bridges as to their type and identity, other than ethernet addres, and draw
the appropriate icon and ident string?

This would really be a nice feature.......keeping in mind, the more the utility
does, the less the user has to do!



3:
When the utility is running and an error or warning message is displayed in
the status window, a user might tend to think that the utility has failed
or stopped or perhaps needs additional input.  

Placing the pointer over the LAN Autotopology window does not change the
pointer into a clock to show that something is active.  With the only
available option being STOP, it is possible that the user could assume
that failure has taken place and stop the process prematurely.

Is there anyway that the pointer could be updated to indicate an active
process?



Thanks,
Al
T.RTitleUserPersonal
Name
DateLines
2901.1Answers to commentsQUIVER::HAROKOPUSThu Apr 30 1992 16:4771
Thanks for your input and interest in the LAN autotopology.


>A few comments on the LAN autotopology utility if you wouldn' mind.
>
>1:
>When the map is drawn, each icon and its corresponding identifier lable are
>drawn a bit too close together.  The only thing that shows where one lable
>stops and the other starts is the period.  A bit broader spacing would help.
>

There should be plenty of room between icons.  Are you sure you are looking
at mapped icons or autoplaced icons?   The stm_fm creates a map file
called mcc_maps:mcc_<32 char domain uid>.mcc_map_<domain_name>

I would like to see this map file. You can mail it to QUIVER::HAROKOPUS


>2: 
>The root bridge appears to be identified not only by its address and the fact
>that it is the root, but it's type is identified and the appropriate icon
>drawn.  Is it possible within this utility, to further identify the other
>bridges as to their type and identity, other than ethernet addres, and draw
>the appropriate icon and ident string?
>
>
>This would really be a nice feature.......keeping in mind, the more the utility
>does, the less the user has to do!


The STM FM should create a spanning tree map 
representation.  Each icon on the map should indicate the bridge type
just like the root.  With the root you have additional information
indicating the spanning tree mode and root id.   It sounds like your
tree did not build successfully.  This would cause all of the bridges (except
the root apparently)
to be autoplaced into the domain by mcc because they are not found in the
map file.  

Could you send me the following files from this run so I can find out what
went wrong?

1) The map file as indicated above.
2) mcc_stm_fm_<domain_name>_messages.log
3) mcc_stm_<domain_name>_autoreg.com and .log
4) A dump of your listener database - You can get this using choice 6 from
the listener menu. 



>3:
>When the utility is running and an error or warning message is displayed in
>the status window, a user might tend to think that the utility has failed
>or stopped or perhaps needs additional input.  
>
>Placing the pointer over the LAN Autotopology window does not change the
>pointer into a clock to show that something is active.  With the only
>available option being STOP, it is possible that the user could assume
>that failure has taken place and stop the process prematurely.
>
>Is there anyway that the pointer could be updated to indicate an active
>process?


This is a good idea.  I've entered it as QAR 2859 in the MCC_INTERNAL
database on NACQAR.


Thanks for your help and I appreciate your comments so keep them coming.

Bob