| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 3093.1 | Ed=Truth | SCASS1::TERPENING |  | Wed Dec 20 1995 20:35 | 5 | 
|  |     If Ed said it, it is true, whatever he says you can take to the bank!
    
    The configurations are stored in the modules, not the MAM.
    
    Regards,
 | 
| 3093.2 |  | NETCAD::DOODY | Michael Doody | Thu Dec 21 1995 10:39 | 18 | 
|  |     The Hub's backplane configuration is stored in the MAM. These are the
    things you set up in Hubwatch's Lan Interconnect screen like the 
    LAN segments and backplane port connections to those lans and whether the 
    FDDI ports point out the front or back. The PortSwitch repeater's front
    panel port assignments to repeater "internal lans" are stored in the
    repeater.
    
    Since the backplane configuration is stored in the MAM, removing the
    MAM from the hub removes the configuration too. When the new MAM card
    is inserted, any existing connections will be deleted.
    
    I don't know what the story is about hot-swapping the MAM card. It
    doesn't sound like a good idea 'cuz I don't think it was designed that
    way. It won't achieve the results you are hoping for because you have
    to re-config... unless you pre-configure the new MAM card in another
    Hub with the exact same modules etc.
    
    -Mike
 | 
| 3093.3 | HOT-swap of MAM module is not supported or recommended... | NETCAD::BATTERSBY |  | Thu Dec 21 1995 10:54 | 12 | 
|  |     I wouldn't recommend hot-swapping a MAM module either. There
    are two ribbon cables that attach to the MAM module card. They
    are difficult enough as it is to detach the berg-style connectors
    from the module without invoking some kind of rocking back-and-forth.
    The same thing applies when plugging in the new MAM module and
    mating to these two connectors without also using some rocking motion.
    In both instances one would be verrry likely be making and breaking
    connections to certain pins with power and other signals in a very
    un-controlled manner which would raise the risk of damage to the
    MAM module.
    
    Bob
 | 
| 3093.4 | MIS-INFORMATION | DELNI::BUZZELL |  | Thu Dec 21 1995 16:58 | 31 | 
|  |     
    
    RE: .0
         
       Well since my name has been associated with this MIS-INFORMATION
    let me see if I can set the rcord straight. In any training where
    this topic hasd been discussed my response has always been that you
    should NOT attempt to hot-swap the MAM. I have also used the example
    that Bob uses in .3 as to why it should NOT be done and compare it to
    the reason we ARE ABLE to hot-swap MODULES and POWER SUPPLIES. You
    should schedule down time to replace the MAM.
    
       When the MAM is removed and replaced with a new one ALL
    configuration is LOST. There will be no IP address or backplane
    channel configuration information on the new one. Someone else 
    from Engineering elsewhere in this notesfile answered a question 
    about pre-configuring a new MAM and replacing it for the failed MAM.
    The response was that one could configure a MAM then remove it and 
    place it in another hub and the config would be intact. I have never
    tried this to confirm it.
    
       RE: .3 THANKS. Its things like that that provide energy when one
    has seen home 1 week in 11.
    
       Alphonse would you please have whoever provide you with this
    information contact me so I can understand how anything I said 
    could even remotely be construed to mean you can hot-swap the
    MAM and even more incredibly have  a configuration in the new one.
    
    Ed
    
 | 
| 3093.5 | more reliable info | NETCAD::CURRIER |  | Fri Dec 22 1995 13:15 | 15 | 
|  |     re .4
    
    we have confirmed that a MAM card retains config info when it is moved
    from one hub to another.  i.e.  use HUBwatch to configure the
    backplane; power down the hub; move the MAM card into another
    (posered-down hub); power-up the 2nd hub --  
    
       ASSUMING the 2nd hub contains the SAME modules in the SAME slots
    
    the 2nd hub will have the same config as the 1st
    
    
    -s
    
    
 |