Conference netcad::hub_mgnt

John,

First, I believe MAM is short for MAtrix Manager.
Second, realize that Hubwatch/MCM is not backwards-compatible
to previous releases of MAM firmware ... whenever we ship a Hubwatch/MCM
kit, it is bound (and gagged) to the version of MAM firmware inside
the consolidated f/w kit that shipped with the version of Hubwatch/MCM.

Now, to answer your specific questions. These are the MCM/MAM
versions that work together, beginning with MAM V4.2. Also mentioned
are the clearVISN releases they are kitted with.

MCM V5.0 <==> MAM V4.2  (clearVISN V1.0)
----------------------
Handles all "older" devices: no VNswitch, no MS600 stack or devices


MCM V6.0 <==> MAM V5.0  (clearVISN V1.1a)
----------------------
Handles all "older" devices, VNswitch (V1.5 module f/w),
MS600 stack and devices

clearVISN V2.0 will have MCM V6.1 and MAM (?) ...


=============================================================
A few thoughts that may help ......
=============================================================

Use Recovery Manager to ride through MAM firmware upgrades
----------------------------------------------------------
V1.1.0 Recovery Manager IS backwards-compatible to MAM firmware
releases (and is currently FORWARDS-compatible to the V5.0 MAM firmware
release). Recovery Manager was designed to keep you moving
forward from module/MAM firmware changes without losing your configuration
data, as well as to create configuration baselines, snapshots, and
auto-configuration capability.

Recovery Manager needs to support previous MAM and module firmware
releases, as the customer wants to save their backplane connections
BEFORE upgrading their firmware (and as you know all too well, when
using Flash Loader to upgrade MAM firmware from one V-release to
another, you wipe out all your parameters in the process). To do this,
you load the latest version of clearVISN, use Recovery Manager to
backup your current hub/backplane, upgrade your MAM firmware, then
use Recovery Manager again to restore your parameters. Once your
VNswitches are in place, Recovery Manager can be used to backup
and restore their connections to the Lan Interconnect as well,
thereby supporting the full backplane regardless of the devices
installed.

In clearVISN V1.1a, it was decided to make changes only to MCM and
Flash Loader, bringing all the clearVISN V1.0 apps "along for
the ride". The VNswitch could have presented a major problem
for Recovery Manager, but Carl Mower's forward-thinking design of the 
Lan Interconnect script allowed us to support any VNswitch backplane
connections without changing a line of code.

Recovery Manager supports the Lan Interconnect (MAM if you will)
independent of media type/technology, thanks to Carl and his
Lan Interconnect script. In clearVISN V1.1a, you can't use Recovery
Manager to back up the VNswitches themselves, but you CAN back up
and restore their connections to the Lan Interconnect backplane.
(The only gotcha we have is that the auto-VNbus enable/disable
is not supported by Recovery Manager, and the desired state
has to be set manually via the MAM console or by MCM).

I hope this helps, and that you get answers to your previous
VNswitch problems.

John Gillis
clearVISN Recovery Manager

    MAM = Management Agent Module.

MAM = Management Agent Module (as in SNMP management agent).

The release notes for MAM versions (DMHUBxxx.txt, .ps, etc)
have always stated what MCM (and, in earlier versions, HUBwatch)
version it is compatible with, and has always given this upgrade
sequence:

	1) upgrade hub with the new MAM firmware
	2) upgrade MCM
	3) upgrade modules in the hub

Leaving a time gap between step 1&2 or 2&3 caused some management
problems back when we transitioned from MAM V3.1/HUBwatch V3.1 to V4.0.
It was less obvious going from V4.0 to MAM V4.1/HUBwatch V4.1/MCM V5.0 
(except with DECswitch900EF).  But now we are again moving between major 
versions.  MAM V5.0/MCM V6.0 handle three entirely new backplane
media types - "More Ethernets" (2-wire), ATM, and VNbus.  

Backwards compatibility between MAM or MCM and previous MAM or MCM 
versions has never been a goal - it costs too much in development
and test time, resulting in later delivery dates with no useful
benefit.

If your customer wants to maintain some hubs at V4.2 and some at V5.0,
then they need to maintain two management stations, MCM V5.0 and MCM 
V6.0.  

	Dotsie
  

  John's (-.1) reply is mostly correct;  just a few small corrections...


> First, I believe MAM is short for MAtrix Manager.

  MAM = Management Agent Module
  (the Matrix Manager is one [large] component of the MAM firmware).



> (and as you know all too well, when using Flash Loader to upgrade MAM 
> firmware from one V-release to another, you wipe out all your parameters 
> in the process). 

  Not true.  When upgrading from Vx.x --> Vy.y you do NOT loose your
  settings, and do NOT loose your backplane connectivity.

  When upgrading from <anything> --> Tz.z you DO loose all settings.
  (Since John, like most engineers around here, upgrade often to T versions,
  most of the MAM upgrades we do cause all settings to be lost, thus his
  perception that settings are always lost.  Customers [should] only ever
  upgrade V-->V, and thus should never loose settings).



> To do this, you load the latest version of clearVISN, use Recovery Manager 
> to backup your current hub/backplane, upgrade your MAM firmware, then
> use Recovery Manager again to restore your parameters. 

  While this would work, I would encourage users to only do the restore 
  operation if (for some unexplained reason) the MAM's settings are in fact
  lost.  I would view a MAM firmware upgrade in the same manner as upgrading
  software on a PC:  backup you disk, install software, then restore from
  backup if the install goes hay-wire.


  Carl Mower.

  While Jon did not ask about this, note the implications of the restriction
  listed in -.2:

      MAM v4.2  ---  MCM v5.0  (part of clearVISN 1.0)
      MAM v5.0  ---  MCM v6.0  (part of clearVISN 1.1a)

  And when clearVISN 2.0 arrives:
      MAM v5.?  ---  MCM v6.1  (part of clearVISN 2.0)


  The short rule-of-thumb is that you must only use together the versions that
  ship together.  No other mixes of MAM & MCM will work [correctly].  The
  LAN Interconnect functionality is especially sensitive to version 
  mis-matches;  using such a mis-match could result in a corrupted backplane
  interconnect.


  Note the implications of this...  If you have a customer with enough hubs
  that they cannot upgrade all their hubs in one session, they will have to
  have two PCs, one with the "previous" MCM version, (v5.0 in this case), and
  another with the "new" MCM version, (v6.0 in this case).

  While you could load clearVISN 1.0 (MCM v5.0) and clearVISN 1.1a (MCM v6.0)
  on the same PC, you cannot easily switch from running one to the other, thus
  the need for two separate PCs.

  Additionally, you will need to carefully guarantee that during the transition
  you use the correct PC/MCM with the correct set of hubs.

  We understand the difficulty this causes, and are working on improving it.

  Carl Mower
  clearVISN.

    A long time ago I suggested some code be written to prevent production
    customers from suiciding.
    
    A case in point - the Kentucky Cabinet for Natural Resources put in a
    DECswitch 900EF in their older hub.  The hub powered it up, ran it, but
    the hub crashed quite a few times a day.
    
    The problem was that the hub was V3.x of stuff and the EF was V1.5
    which supported a whole new set of ligotypes.
    
    THEY were ready to TOSS OUT ALL DIGITAL because of the total havoc that
    this created in a critical network area.
    
    Now nobody ever made it a requirement of products that the customer
    read the release notes.  It is not a job requirement of their IS
    director that he or she read product release notes.  And, they don't
    have to buy Digital.  After enduring a month of hub crashes, it was
    really not very consoling for us to point out that we created a product
    which would - by just plugging it in - cause total chaos on a critical
    care of their network.
    
    A LOT of knee padded begging went on there on the part of Bill Decker
    and myself to keep us in the account.  I believe that I just GAVE them
    an EF to keep 'just because' they were nice folks.  (That's $8k of list
    that Digital ATE because of this...)
    
    Back before dirt was dirt and I was writing software, it was considered
    rude for software to abort under any condition.  I think that the same
    condition applies.  Software that is too stupid to detect basic
    incompatabiltiy in a complex system and prevent unwanted side effects
    should NOT exist.  
    
    It's easy to do that.  Simply do a version/compatibility check and NOT
    run.  (VMS does it - "Ident mismatch" - I'm about to suicide your
    computer so I'm NOT going to run this.)
    
    We have GOT to do the same types of things if we want to scale our hubs
    up.  DEMANDING that the customer do things is NOT the way to build user
    friendly products.  It is NOT a winning strategy.  Period!
    

So Jon,


You dudes would be happy when 'seed' units sit in a hub fat & dumb ... but not happy because the MAM code doesn't
recognize the device and MCM pretends it just doesn't exist.

The hub is a whole different (buzzword alert) paradigm.  There are three entities which are really systems in & of
themselves forming a system together.  Choices had to be made based on many contingencies ..  resources, time to
market, 2nd & 3rd party development.

We know that we can't make all the people happy all the time.  We just do the best we can.

I also don't like the fact that certain devices/software are not backwards compatible, 
but sometimes it can't be helped, ie new functionality. We have the same issues with
CPU's, certain versions of console code won't recognize certain new products that are 
released. So you need to make sure those are up to rev. I believe it should also be part 
of the salesperson's job, to know his/her product and should advise the customer
of the prerequists(sp?) to installing a new product. I've learned a long time ago,
customers don't read the release notes, so I make sure I read them for 'em.

Brad

    I'm very concerned about the fact that a customer has such old rev
    HUB firmware, and how this type of problem will manifest itself.
    I'm even more concerned that if this HUB/DECswitch900EF was sold to
    the customer referred to in the note 4268.6 by a certified Distributor
    of ours, that the Distributor ought to get a boot-in-the-pants
    by us for not doing their job better of advising said customer of
    the ill's of firmware incompatibilities. These VAR's are supposedly
    put through a set of training sessions, on how to hand-hold 
    customers, keep in touch with them, and thus eliminate much of this
    type of problem of occuring.
    We put a lot of effort into our accreditation and certification
    program for our resellers to take advantage of.
    
    So I'd be curious Jon how the mis-match occured this badly. 
    Especially given that the change from one of those old revs.
    of HUB firmware had some significant changes done to it.
    
    Bob

    RE: .-1
    
    A DISTRIBUTOR distributes - doesn't really care about checking revs,
    just getting products out the door. Period.  A reseller, sells, again,
    doesn't really do the checks, etc.  An INTEGRATOR (if they are good)
    may do the checks and balances.
    
    Customers buy what they feel are COMMODITY products from the folks
    above.  Their added value is, at best, questionable.
    
    re: .-2
    
    Yes, reading the release notes are fine - but it's difficult to know
    WHERE what release notes are etc.  (For example, I JUST found out that
    the CLEARvisn release notes were NOT in the text file but in the
    on-line pull-down etc.  Sigh.)  And, often you walk into customer
    situations with modules that you have NO idea what the firmware revs
    are, what the release notes for the past 4 modules of past 5
    generations of firmware/interactions are etc.
    
    
    re: .-3
    
    Balderdash!  At least we ought to WARN folks about major
    incompatabilities.  i.e. "Doing this action will DESTROY you lan
    interconnect on the backplane....are you SURE you want to do this?"
    
    Yes, we DO need to give folks the ability to field test and do early
    releases.  But for the customer (like Duquesne University) who was
    hoping to manage their hubs on their old Alfer station - and have
    grudgingly moved to a PC (with alfer beside it) and now just got a
    VNswitch with firmware out of rev, and called me yesterday about
    it....well...do I have time this week (in Cleveland 3 days, chicago one
    day) to babysit them thru a firmware upgrade, let them know that they
    needed to order the new software because we didn't tell them about it
    in ANY catalogues and help them upgrade their 30 or so hubs.  It just
    does NOT scale and is broken.  Period.  In order to manage their new
    flippen VNswitch they need an OLD hub manager (to manage their old
    hubs) and a NEW hub manager to manage the ONE STUPID HUB with a
    VNswithc.
    
    Get real...that is NOT how people do production network management.
    
    AARUGH.
    j
    ^--who is toasted
    
    

    RE: .-1

    Will you quit with the "Alfer" already?  I'm not involved with either
    Digital Semiconductor or the Alpha system groups, but it grates every
    time I see it.

    re: .-1
    
    Oh chill....try running MCM on it or MAPI.....it will grate even
    more.
    j