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

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

1298.0. "Foreign (Emulex) Terminal Servers" by TROOA::GILBERT () Tue Jul 30 1991 19:38

    Get out the guns and arrows...but I have to ask it.
    
    Is there any intention of allowing non-Digital terminal servers to be
    controlled by DECmcc?  I have a customer who has many many Emulex
    terminal servers.  They are currently able to use them in all
    situations where DECservers are normally used (ie. terminals, printers,
    even VAXcluster console connections until I pointed out that wasn't
    supported).
    
    Anyway, I expect the standard answer would be that the Emulex should
    put out a TSAM of their own.  However, I don't think that will ever
    happen.
    
    I will probably not be able to convince them to use the TSAM for the
    few DECservers they have, although I love the product!  
    
    Any comments on this area of support?
T.RTitleUserPersonal
Name
DateLines
1298.1sorryTOOK::L_CARDANITue Jul 30 1991 20:028
    As of now, the plan is to support DEC servers only.
    
    Once we move to SNMP-managed terminal servers, that could change. 
    Until then, TSAM is HEAVILY dependant on the user interface.  As
    close to DEC TS interfaces as most competitors are, it would still be
    unreasonable to try to support them all for now.
    
     - Linda Cardani
1298.2SNMP TS Management and DigitalENUF::GASSMANWed Jul 31 1991 12:0811
    Even when DEC terminal servers move to SNMP - other vendor's servers
    will need to be managed differently.  There is an IETF TERMINAL SERVER
    MIB (experimental at this point), which many terminal servers will no
    doubt migrate to.  The DEC terminal server will use the IETF ASCII MIB
    (experimental also), to move data back and forth between the SNMP
    manager and the TS-SNMP Agent.  Since any ASCII management depends on a
    lot of good parsing - support of other vendors who try to clone the DEC
    terminal server will be as good as the vendor is at cloning.  I would
    not expect Digital to support other vendor's poor cloning.
    
    bill
1298.3we welcome someone to develop an Emulex AMTOOK::MATTHEWSThu Aug 01 1991 18:5629
    DECmcc is an open system. If Emulex wishes to provide an Access
    Module to support their terminal servers using an Emulex specific
    management protocol or they wish to provide proprietary MIB extensions
    beyond those in the standard IETF Terminal Server MIB they can do
    so. If they want most favored vendor status (similar to the usa's
    most favored nation trading status) they can negotiate that with
    the Strategic Vendor Program. In addition, if some other organization
    thinks they can make money by providing an Emulex specific AM they
    are free to do so (this includes integration services within DEC).
    If a DEC customer desires this enough to do it themselves or hire
    DEC to do it for them, I am sure we could do it.
    
    The DEC terminal server development group is not planning to support
    Emulex. Network Management Engineering will provide generic support
    via SNMP and OSI CMIP only and someone else is responsible to integrate
    the Emulex specific objects into the AM of choice. 
    
    Network Management Engineering has no intention of being exclusionary
    or blocking anyone from management of an object via DECmcc. We gladly
    encourage everyone to use it, that is why we are actively helping
    multiple third parties (ie. VitaLink, Stratacom for example). However,
    we and the terminal server development people, have a finite set of
    resources to work with. We have to use those resources where they can
    achieve the most good. I would believe that Emulex has the most to
    gain in this case and should be responsible to see that their products
    can be managed by DECmcc. 
    
    wally matthews
    
1298.4Has anybody tried TS AM against Emulex?OSLACT::BJORNOnce againWed Mar 04 1992 09:5110
1298.5Use SNMP AMTOOK::CASSIDYLinda, LKG2-2/BB10, DTN 226-7270Thu Mar 05 1992 12:2913
TSAM does not use SNMP, so the presence of an SNMP agent on a foreign terminal
server does not mean any TSAM support.  I fact, TSAM will not work on any
non-DEC terminal server due to TSAM's dependence on the terminal server user 
interface.  TSAM is actually "reading" ASCII output from the servers and 
translating it into MCC information.  This means that TSAM has to know exactly
what to expect in the user interface.  Foreign terminal server user interfaces 
are beyond our control and so TSAM really can't support them.

An SNMP agent in the terminal server does mean that it may be manageable via
the DECmcc SNMP AM though.  You would register the terminal servers as SNMP 
entities instead of as terminal_server entities.

 - Linda
1298.6OSLACT::BJORNSoon to be changing dipersThu Mar 05 1992 13:328
1298.7Go for SNMPTOOK::FONSECAI heard it through the Grapevine...Thu Mar 05 1992 20:1811
Even if the foreign terminal server returned output which was 100%
identical, TSAM would not support it.  During registration, TSAM
requires you identify the server type, and the MOP ID for the server
must match, so there is no faking it out.

(By the way there is no such thing as 100%, even with our own terminal
servers... TSAM has special-case code inside for every server we do support.)

Yes, SNMP is the way to go...

-Dave
1298.8further explanationTOOK::CASSIDYLinda, LKG2-2/BB10, DTN 226-7270Fri Mar 06 1992 13:3622
I don't want anyone to get the impression we deliberately decided not to support 
foreign terminal servers just to be difficult - the reason TSAM does the check
Dave mentions is because we can't guarantee what a foreign server user interface
will look like, as I and Dave said before.  

I think that Emulex does try to copy our user interface.  I know that Xyplex 
does.  But they don't copy it closely enough - there are all kinds of slight 
differences in keywords, punctuation, etc.  These differences seem trivial, but
they are enough to cause TSAM to return with bogus information from interpretting 
the screens wrong.

So the decision was made to only support the terminal servers we really "know" -
Digital's.  And like Dave said, that's hard enough because there are different 
groups that develop Digital terminal servers and they naturally come up with 
slightly different interfaces.

I know that reading and translating terminal server output seems like a crazy 
approach since it does bind TSAM to the servers so closely, but until SNMP is
fully implemnted on the servers, that's the way it is.

 - Linda
1298.9a comment from the curmudgeonTOOK::R_SPENCENets don't fail me now...Thu Mar 12 1992 16:324
    Also, be carefull in bidding unannounced products!! If it isn't
    announced, you can't sell it.
    
    s/rob
1298.10How fast do You sell DECmcc?OSLACT::BJORNSoon to be changing dipersFri Mar 13 1992 07:349