Conference netcad::hub_mgnt

What is the configuration?

Does HUBwatch continue to perform normally?

    hi,
    
    re .0
    
    I have a customer also reporting the same messages when invoking
    hubwatch. Hubwatch continues and is successfull in retrieving port
    stats, however unsuccessfull in invoking the general management window
    for a DECbridge 900mx, (DECswitch 900EF).  The customer has no problems
    managing a concentrator 900.
    
    My customer has an old versions of both the bridge and hub, v1.2.1 and
    v2.2.1 respectively. 
    
    The erro log on bridge shows 4 entries, three of these seem to the
    same.
    
    The entries are as follows (I will include one entry and supply the
    differences from this initial for the other).
     
    Entry #		= 0
    Entry status	= 0 [0=valid, 1=write_error, 2=invalid,
    			     3=empty, 4=crc_error]
    Entry id		= 11
    Firmware rev	= 1.2
    Reset Count		= 5
    Timestamp		= 0 CC E497
    Write Count 	= 31
    FRU Mask		= 0
    FRU Mask		= 1FC
    Error data		= SR=000A  PC=00000000 Error Code=00000000
    			
    			 0:0000000A  1:00000000  2:00000000  3:00000005
    			 4:00000049  5:00000000  6:0000001B  7:00000000
    
    
    Entry #             = 1
    Timestamp           = 0 CC E39D
    Write Count         = 30
    Error data          = 4:00000064 6:0000001A
    
    
    Entry #             = 2
    Timestamp           = 0 CC E3EA
    Write Count         = 30
    Error data          = 4:00000064 6:0000001A
    
    
    Entry #             = 3
    Timestamp           = 0 CC E448
    Write Count         = 30
    Error data          = 4:00000064 6:0000001A
    
    
    thanks in advance,
    
    Anup Patel 
    

.2, I'm surprised that configuration works at all!
The hub and bridge versions are too old for that version -
you'd need DEChub V3.1 at least.  But don't bother with
that, because they are both severely out of date.  

Please please have your customer upgrade.  DEChub V4.1,
DECswitch900EF V1.5.2, etc - see Note 2. 

	- Dotsie

    re .3
    
    You missed the part about HUBwatch for VMS in .0.   There isn't any
    HUBwatch for VMS V4.1.1 to support the new firmware.
    
    By the way, does anyone out there really need a new release of HUBwatch
    for VMS for their customers?  Just checking....
    
    Bill Wade
    Network Product Support                
    

Even to work with Hubwatch V3.1.x, .2 is out of rev.
Hubwatch V3.1.x needs DEChub V3.1 and whatever DECbridge
version went with it, just like I said.

	Dotsie

    re .5
    
    And all I'm saying is don't go to MAM 4.1 and DEFBA 1.5.2 and expect
    to manage it with HUBwatch for VMS 3.1.1.
    
    The previous rev of the firmware that works with HUBwatch for VMS 3.1.1
    is located at anonymous ftp site ftp.digital.com in directory 
    /pub/DEC/hub900/prev_fw/hw3_1_fw/firmware.
    
    
    Bill
    
               
    
    

    
    re .3/.5 & .4/.6,
    
    
    Thanks. I was aware that the customer is on old versions and already
    had action to upgrade to mam v3.1.0 and corresponding modules. Cannot
    take customer to v4.1 at the moment.  
    
    I wanted to know if anyone can add value to errors with hubwatch and 
    the error log dump information.
    
    
    Anup Patel.

    RE: .2  That error log data for the DECswitch looks funny. 
    Perhaps it's typed incorrectly. I've stared at many error logs
    in our lab here in LKG and the one entered here doesn't look quite 
    like the ones I've seen. There appears to be two lines labeled with
    "FRU Mask". The second line with this label should have been labeled
    "Test ID" as the  = 1FC is a firmware test code type seen on older rev
    DECbridges with firmware rev 1.2.1. This rev firmware had some bugs
    related to FDDI which generated the Test code 1FC and should be 
    upgraded to avoid this problem.
    
    Bob

    I have a customer that is an all-VMS shop, using HUBwatch on both the
    PC and OpenVMS etc.  They've been mucking with managing the hub with
    both (which is at the latest firmware) and ran into a DECswitch 900EF
    problem in which they could NOT flip a bridge port from the backplane
    to the front.  Nor could they delete a FLEXlan that they created.
    
    We did a reset of the MAM (which ended up crashing their FDDI cluster!)
    and after that were able to flip the port but NOT delete the LAN.
    
    I suggested some scheduled downtime (this IS a production 24 x 7) with
    a few VERY NARROW windows scheduled for maintenance - and reseting 
    EVERYTHING to factory defaults.
    
    If we are NOT going to release timely, coordinated versions and put
    production customers into jeopardy, perhaps we could code things to
    explicitely NOT WORK so customers we don't provide software that breaks
    their production environments!
    
    p.s. my demo room config has a VAXstation managing V4(mumble firmware)
    with the ONLY FRIGGEN OpenVMS version available.  I can't order new
    demo gear just because we don't want to release timely cross platform
    versions.
    
    BIG GRUMBLE,
    j
    ^--who understands time/schedules/etc. but that is MANAGEMENTS job to
    make things happen to time and schedule to INSULATE customers from
    these issues!

    Bye the way,
    The problem discribed in 2926.0 disapeared, when the customer reloaded
    the agent in the HUB900.
    The customer found out about this, because he had a other problem with
    HUBwatch and a HUB90. He reseated the agent for this hub, and it worked ok.
    Then he try'ed reloading the HUB900 agent.
                                                Jan.

    Bob,
    
    re .8
    
    You are right, my mistake the label following "FRU Mask" should have been
    "Test ID".
    
    
    Anup