| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2887.1 | I don't think so | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Thu Apr 30 1992 13:28 | 15 |
|
In my opinion, no, TSAM probably won't support third party NON-SNMP terminal
servers.
We're an open vendor now, but we sure weren't a few years ago when all the
ASCII-managed terminal servers were developed. And now we're left making those
servers "fit" into mcc-style management. That is done by scanning and
translating ASCII output. So you can see why supporting foreign servers is a
problem.
rom now on terminal servers (DEC and third party) should have standard
management agents and will be manageable via the SNMP AM. So eventually
the problem should go away, or at least become less critical.
- Linda Cassidy
|
| 2887.2 | DECmcc selling point | SUBWAY::BEAZLEY | | Sat May 09 1992 14:19 | 19 |
| Linda,
I do understand your reasoning regarding the parsing of third party
ASCII text. To incorporate every format is not realistic. But, what
about third party vendors that write to the Digital format? For
instance, Xyplex and Datability. Today our customers can manage these
vendor's servers via the Terminal Server Managment point product. So,
wouldn't it make sense to allow for the management of conforming
third party vendor products under DECmcc? Unless there is some other
underlying issue here, serious thought should be given to this issue
before we (DEC) tell our customers to give up TSM point for DECmcc
TSAM. This is definitly a problem. I can't tell the customer; oh by
the way you can't manage your non-Digital terminal servers via the
TSAM. How hard can it be to disable software version checking?
Just trying to UNDERSTAND,
Bob
|
| 2887.3 | further explanation | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Mon May 11 1992 14:08 | 31 |
| I talked to Bob this morning and explained the problems around this issue a
little better (I hope!)
You're right, Xyplex and Datability's user interfaces do match DEC's quite
closely. BUT, not 100%. That means that 1) some attributes that the servers
may have will not be available to the TS AM, and 2) it is very conceivable that
some of the attributes or values the servers may have could actually be a
problem to the TS AM. Remember that the TS AM is actually reading the server
output and trying to convert it into standard DECmcc dictionary attributes and
values. There is no way to guarantee that the TS AM will react gracefully for
every possible value for every possible attribute on every third party server.
It could do a lot to be defensive, but I don't think I'd ever claim it was
perfectly safe.
Many people suggest letting the user try to manage the third party server, with a
disclaimer that it may not work as expected. But we felt it is just too risky
to operate with that level of unpredictability in an integrated management
system which could be controlling entire networks.
Also, keep in mind that once terminal servers support a standard management
protocol like SNMP, they can and should be managed that way. Eventually this
will not be an issue. The TS AM was meant to be a solution to get our
customers by in the interim.
Bob had some good suggestions and I am planning to work with product management
to continue working on the issue and also to provide our sales force with a
message to give their clients so that we minimize the impact of this problem.
Feel free to post any comments or suggestions you have.
- Linda
|