Conference netcad::hub_mgnt

>	in a configuration with a hub fully populated with 8 FDDI 
>modules and chained by a tree in the backplane and the tree root 
>being in slot 1 ( so all others modules are connected from left to right ) :
>
>AB-C1-m---S-C2-M---S-C3-M----S-C4-M---S-C5-M---S-C6-M----S-C7-M---S-C8
>


   Not exactly... they are connected left to right, as you say, however since
slot 1 is the root it appears after slot 8:  (this is similar to diagram #28
in the FDDI configuration guide in note #2340).


	-Assuming MAM firmware V4.0 or later-

                            DEChub900MS 
                            ===========

        1      2      3      4      5      6      7      8

Front
       A B
      +---+  +---+  +---+  +---+  +---+  +---+  +---+  +---+  
      |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |
      |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |
      |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |
      |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |
      |   |  |   |  |   |  |   |  |   |  |   |  |   |  |   |
      +---+  +---+  +---+  +---+  +---+  +---+  +---+  +---+  
       M        S    M S    M S    M S    M S    M S    M S
Back   |        +====+ +====+ +====+ +====+ +====+ +====+ |
       |						  |
       +==================================================+




>1) when a module is removed , its backplane connections are lost 
>and there is no automatic reconnection of its adjacent modules , so
>that the modules to its Right are isolated from the root 
>
>for instance , if C4 is removed , the token flow from the root (C1)
>ends in C3 , and C5 to C8 are isolated 

	FALSE.

	When a module is removed, the adjacent modules are automatically
	connected to each other. This is true whether auto-healing is 
	enabled or disabled, it is true whether the Hub is powered or not
	(hot-swap/cold-swap).

	In your example, if C4 is removed, C3 is then connected to C5.

	(Historical note: This was also true with V3.1.0 MAM firmware but only
	  for the hot-swap case)


>2) when another module of the same type is re-inserted in the same 

	Well, since you said FDDI auto-healing is disabled, it is
	irrelevent whether it is the same-module-type.

>slot , when it is  connected to the FDDI tree ( either by manual setting or 
>with the soon coming backup/restore function ) , the modules that 
>are adjacent to it are the same than before the removal 

	TRUE.

	The token flow order is maintained.

>so when C4 is back , it is reconnected to C3 and C5 , and the token flow is 
>again from C1 to C8 

	TRUE.
	

	However, realize that if you had set up the hub with the old 
	firmware, the token order was defined at that time, and it was
	not in slot order. It will appear somewhat random. When you 
	upgrade the hub, the upgrade process does not rearrange the token
	order; it stays in whatever order was present. However, as you 
	make/break connections with the new hubwatch it will gradually
	put it in the new defined slot order.


	-Mike

	thanks for your explanations about token flow ordering 
and the way hot-swap is handled with V4 

( by the way , all modules will be upgraded to V4 because they need
FDDI trees ) 

in fact i was confused about how auto-healing was used and didnt make
the distinction between auto-healing feature and the way hub manager 
reconnects modules on removal of module 


regards PJ

    Yes, the main difference over the v3.1 code is that
    	- cold swap reconnection works.
    	- module reinsertion is automatic when auto-healing enabled.
    
    md

    Don't forget ....
    
    
    When you do the upgrade, you must upgrade hubwatch, the mam, & the fddi
    modules without any lan interconnect view actions.  You may NOT mix
    & match old & new software/firmware.   While in the upgrade process
    DO NOT change a LIGO config, add or delete a matrix connection, or
    refresh the lan interconnect screen.