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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

2292.0. "hubwatch general protection fault 001A:BAOE" by KERNEL::WARDJO () Thu May 18 1995 09:51

    Hello,
    
    I have a customer with two dechub 900s, each with two decbridge 900MX
    in them. When the customer added the second bridge to one of the hubs
    they seem to get problem managing the hub with hubwatch for Windows, this 
    results in the message "an error has occurred in your application etc
    etc", followed by "hubwatch caused a general protection fault in
    hubwatch.exe  001A:BA0E".
    
    The customer fires up hubwatch a enters the name of the agent, a
    picture of an empty hub appears, the customer then has to enable
    polling and do a refresh inorder to see the two decbridge 900s.
    
    Having got a picture of the modules in the hub, the customer can click on 
    the bridge and bring up the expected window for the bridge. If he then
    clicks on the "FDDI" option the next window appears, but trying to
    scroll down the ports causes the error.
    
    Anyone seen this before?
    
    Hubwatch for Windows X3.1.3   (is this later than V3.1?).
    Decbridge 900 V1.4.4
    Mam V3.0 (am getting customer to upgrade to V3.1).
    
    PC is a Compaq pro linear 4/66 with 12meg of memory, running windows
    for workgroups & microsoft tcp/ip.
    
    Hubwatch is the only application running.
    
    Thanks for any help
    
    Jon
                                     
T.RTitleUserPersonal
Name
DateLines
2292.1Get the SSB versionNETCAD::FORINOThu May 18 1995 10:0712
    One basic rule of the road is that if you see a version of HUBwatch
    with a X instead of a V in front of it you are running an pre-SSB
    software baselevel of the product.  It is therefore UNSUPPORTED!!
    
    I realize some of these do get into the field for demo or test
    purposes before the SSB kits become available.
    
    So if this is the case you should upgrade to the SSB version of
    HUBwatch as a starting point before you spend time trying to
    fix a customer problem.
    
    							John
2292.2Xa.b < Va.b --- ALWAYS!SLINK::HOODMaine state bird: The black flyThu May 18 1995 11:3926
>    Hubwatch for Windows X3.1.3   (is this later than V3.1?)
No.  

Tom's Official Guide to Digital's Official Software Version Numbering:

Xa.b.c or Xa.b.c-d
   This is a DEVELOPMENT version of software.  Here, we're talking strictly
   "use this at your own risk and update to the V version as soon as it is
   available".  Xd.e.f is a predecessor to Vd.e.  (HUBwatch also uses "X"
   versions a field-test versions)
Ta.b.c or Ta.b.c-d
   This is a somewhat supported FIELD-TEST version of software. (HUBwatch does
   not generally use "T" versions.)
Va.b.c or Va.b.c-d
   This is an official released version of software.  "a" is the primary
   version, usually incremented on MAJOR function changes or additions.  "b" 
   is the update version, initially 0 on any primary version, incremented on
   smaller function changes or additions.  "c" or "c-d" are generally used only
   for internal tracking

Anyway, we in HUBwatch make X versions until a couple of days before SSB
submission, when we change the "X" to a "V" (and the ".c" to  ".0").  If we
mess up somehow, we will increment the .0 (in the .c position) strictly
for tracking purposes, but there is only one official Va.b version.

So, X3.1.n is *always* earlier software and less reliable than V3.1.
2292.3Problem Fixed!KERNEL::WARDJOMon May 22 1995 06:247
    Thanks for the replies,
    
    After upgrading the MAM the problem went away. I have suggested
    customer also install latest SSB version of Hubwatch.
    
    Jon