Conference netcad::hub_mgnt

    Most of the setup port information is available from the HUBwatch
    screens.  Note that at least one visit to the console is necessary
    to assign an IP address, in order to be able to use HUBwatch.
    (One way to set up a "remote console" is to use reverse LAT to make
    the setup port available on a terminal server port.)
    
    Anil

       
    
    That is exactly the problem. The information is only available
    from the hubwatch screens. Dont get us wrong, Hubwatch is wonderfull.  
    The Hubwatch application is not every where, all the time. A character
    cell terminal is almost always available. 
    
    Please do not take this request lightly. 
    
    The purpose of the request is from the trouble shooting 
    perspective. There is a need to rapidly accesss the hub 
    and start the problem resolution process.
    
    From any where at any time.
    
    It is unacceptable to say to a angry user --- I'm sorry we cannot 
    address your problem now - our hubwatch PC is in 
    another location, and I'm blind without it. 
    
    
    Jim
    

The topic of a character-cell interface to all the hub (and device) data was
discussed in detail some time ago on the project.  And the answer then was no.

The reason why there isn't a character equivalent to HUBwatch (or even a good
subset) is that doing so would require about twice the development time.  Not
only would firmware developers have to do an SNMP interface, they'd also need 
to do a command line interface.  Not only would HUBwatch developers have to do
a GUI interface, they'd need to do a command line interface.  

What this comes down to is in order to do a character interface to the hub, 
we'd have to NOT do something like FDDI trees or support for a new repeater 
or the backup and restore utility.  We are *severely* limited by development
resources, and we do the things that get the most bang (read that "dollars")
for the buck.

As far as a char cell being available, HUBwatch for Windows is available for
the bargain basement price of $495, and runs on most PCs.  That was priced
cheap to cover this exact problem.

As a workaround, the setup port of the hub can be connected to an async port
of a nearby workstation.  SET HOST /DTE is the command in OpenVMS to get to
that port.  Someone else here mentioned you can do the same thing by connecting
it to a terminal server and using reverse LAT .

Tom Hood
HUBwatch

    I understand the need to focus on priorties and am trying to suggest
    an alternative way of providing this functionality without the
    need to have the firmware developers provide a character cell interface
    on a per module basis. 
    
    Could the Hub management module firmware address this task. 
    As I understand it the hub manager has the ability to "talk" to the 
    modules and obtain some basic information. Could the functionality of 
    the Hub management module be enhance to provide some basic 
    bridge counter information. 
    
    I understand this could then be accessed via reverse lat, dial in 
    modem, or the workstation set host/dte method.
    
    Jim
    
           
       

    If we did something in the hub manager only we would break our
    (very powerfull) story that modules are the same in a hub as in a
    docking station, so realistically we would have to do this for
    everything.

    More importantly, though, it really would be a very large amount
    of work.  We would have to:

    Build a remote access method - this would involve implementing
    both Telnet and TCP (these are the obvious choices - anything
    equivalent in functionality would be as much work for less
    interoperability).

    Build a console interface - don't underestimate this; first you
    have to get people to agree on what the interface should look like
    (easily several weeks work alone; no, I'm not exaggerating), then
    you have to build it.

    The complexity of all this is pretty high - it is always harder to
    implement a management function if there is more than one way to
    invoke it, and more opportunities to create bugs.

    Perhaps most important of all, this adds a huge new area that must
    be tested; as resource-constrained as development is, testing is
    almost always worse because they have to test the _combinations_
    of the things that development builds.  The size of the job
    increases geometrically, not arithmetically, with each new product
    or feature.

    What this all boils down to is that we`ve chosen to focus on
    having the best SNMP management capability in our market by fully
    commiting to it, and we stack up very very well against the
    competition on that score.

    Development needs and wants feedback from customers and the field
    about what we should be doing next, but there is only so much that
    can be done.

    The author of some very successfull freely-available software
    recently conducted a poll on the Internet of what features people
    thought should be in his next major release.  He assembled a large
    list of features that had been suggested and allowed anyone who
    wanted to send in votes to do so.  There were two kinds of votes:
   
        Yes to add the feature
        No to _not_ add the feature

    Anyone could vote any number of times, but for each Yes vote, the
    person was _required_ to make at least one No vote for some other
    feature.  There was no limit on the number of No votes a person
    could cast.

    It may be of some small consolation but I have found a laptop +
    Ethernet card is the only way to manage and truobleshoot a growing
    DEChub Network. A laptop can provide you with the terminal emulator for
    configuring the HUBmanager and HUBwatch for configuring the devices.
    
    On larger DEChub projects it is probably worth including a LAPtop with
    your quotes.