| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 630.1 | DECnet Address Optional... | SCRPIO::LIZBICKI | | Thu Jan 17 1991 11:46 | 15 |
|
Simon -
With regards to the DECnet database set-up, the Terminal Server AM,
like the TSM product , allows you to specify a DECnet address (along
with other DECnet-related attributes, like image file name, dump
file name, etc) for a terminal_server. If a DECnet address is specified,
the Terminal Server AM will call the DNA4_AM to propagate DECnet-related
information to the DECnet database. The DECnet address is optional
for all terminal server types; however, it is required for down-line
loading high-end (DECserver 500 and Ethernet Terminal Server) servers,
and may be used for receving up-line dumps from any server type.
Lynne Izbicki
|
| 630.2 | TSM going away as a separate product? | INFACT::NORTHERN | Those slithey toves are gyre and gymballing again | Mon Dec 09 1991 12:04 | 8 |
| Our customer has heard somewhere that the TSM product itself is going
away as a standalone product?
I don't really have the time to do a lot of indepth research to find an
answer, if someone could provide a short "Yes" / "No" / or pointer to
an answer, it would be greatly appreciated.
Lou "The inundated" Northern
|
| 630.3 | YES, eventually | TOOK::R_SPENCE | Nets don't fail me now... | Mon Dec 09 1991 13:00 | 9 |
| The official answer should come from Product Management (so they should
correct me if get something wrong).
It is intended that when most (meaning very large % of that which is
used) functions of TSM can be done with the TSAM in DECmcc, then
the product will be retired (meaning as I understand it, no new
development and no new orders for it).
s/rob
|
| 630.4 | More input needed on TSM | INFACT::NORTHERN | Those slithey toves are gyre and gymballing again | Tue Dec 10 1991 13:34 | 26 |
| Yes,
I would love to contact someone in product management to get an
idea of what is going. Anyone have a node::name I can contact?
My problem is that we have a distributed network over the world,
and each corporate "site" has it's own tsm (for when gophers dig up
cables and the like).
NOW, I am hearing from my customer's telecom group that "TSM is
DEAD", they are going DECmcc (They seem to like it; I can't say as I
don't have the environment to play with it, or even know at this point
exactly what is there to play with).
BUT, they are saying that it uses so much resource that it wouldn't
make sense to replicate what they are doing now (I.E. outlying sites
handling their own TSM management).
Any thoughts on how the future would look to these people? I.E.
can it be bought in a flavor that simply replaces TSM, if that is all
anyone is really interested in in outlying sites? How much effort are
we talking needed to config things, etc.?
As usual, any help would be greatly appreciated.
- Lou
|
| 630.5 | | TOOK::MINTZ | Erik Mintz | Tue Dec 10 1991 14:22 | 3 |
| You can contact Steve (DELNI::S_LANE) Lane, although
for TSM specific issues he may point you to someone else.
|
| 630.6 | TSM/TSAM issues | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Wed Dec 11 1991 10:43 | 2 |
|
The TSM and TS AM Product manager is Junell Silver (DELNI::J_SILVER).
|
| 630.7 | striped down MCC with only required modules | TOOK::CALLANDER | MCC = My Constant Companion | Tue Jan 14 1992 14:22 | 10 |
| another item to note. I understand the shy attitude towards replicating
their entire mcc enviroment everywhere they are currently running TSM,
that would be overkill and unneccessary. MCC was designed as a
plug-and-play tool allowing youto move/use only those components/pieces
that you require. This means a striped down MCC with only the TS AM
(and for future terminal servers the SNMP AM) would be all that is
needed. I believe packaging is being set up so that they can obtain
only those items needed, keeping their environment small enough to
hopefully run where they have TSM now.
|
| 630.8 | Does Director + TSAM qualify as stripped? | TOOK::MINTZ | Erik Mintz, DECmcc Development | Tue Jan 14 1992 15:42 | 6 |
| > that you require. This means a striped down MCC with only the TS AM
> (and for future terminal servers the SNMP AM) would be all that is
The V1.2 packaging scheme will allow the TSAM to layer on the
Director package. I do not know of any further stripping.
|
| 630.9 | TSM version 1.5 ? and 90L+ | YUPPY::MCINTYRE | | Thu Feb 06 1992 05:48 | 10 |
|
does anyone know if TSM v1.5 is shipping, I have heard that this
version is necessary to manage the DECdesver 90L and 90L+ ?
Any help would be much appreciated.
Regards
Tom
|
| 630.10 | TSM V1.5 - DS90L | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Thu Feb 06 1992 09:00 | 2 |
| TSM V1.5 supports DS90L, but not DS90L+ yet. And yes, V1.5 is shipping. By
the way, there is a notes file if you have further questions - NOTED::TSM.
|
| 630.11 | TSM versus T.S.A.M. | MARS02::THOMAS | | Fri Feb 14 1992 09:32 | 22 |
|
I ask a few questions to compare the solutions : TSM or T.S. ACCESS
MODULE.
What are the supported terminal servers with the T.S.A.M. ? ( ETS,
DS 100, 200, 250, 300, 90 ...) I didn't find the T.S.A.M. SPD.
What are the functionnalities that are only available with TSM ? and
when may we expect them with the A.M. ?
What are the functionnalities that are only available with the T.S.A.M
(map, alarms ...) ?
With the T.S.A.M., have we more options:
* to manage performance of terminal servers,
* to trouble shoot terminal servers (on the ETHERNET side and on the
terminal side) ?
Thank you for your comments.
Bernard
|
| 630.12 | | TOOK::FONSECA | I heard it through the Grapevine... | Fri Feb 14 1992 14:07 | 34 |
| Bernard-
You seem to have a pretty good feel for the major differences between
TSAM and TSM already. I would suggest you look at the TSAM release notes
to learn more.
> What are the supported terminal servers with the T.S.A.M. ? ( ETS,
>DS 100, 200, 250, 300, 90 ...) I didn't find the T.S.A.M. SPD.
TSAM will not support ETS. This release does not support the DS90L+ and
MUXserver 380, the rest are supported right now.
> What are the functionnalities that are only available with TSM ? and
>when may we expect them with the A.M. ?
Almost all of the functions in TSM are supported (except the partition
features, which are only partially emulated by using domains.)
> What are the functionnalities that are only available with the T.S.A.M
>(map, alarms ...) ?
You got it.
> With the T.S.A.M., have we more options:
> * to manage performance of terminal servers,
> * to trouble shoot terminal servers (on the ETHERNET side and on the
>terminal side) ?
I would not say that TSAM has more options. DECmcc provides more options through
all of the other AMs available, which as you said allow troubleshooting
ethernet etc.
-Dave
|
| 630.13 | | NYFDIN::SAMBAMURTY | Raja | Fri Feb 14 1992 16:06 | 14 |
| Dave,
Re: -1>
>>What are the functionnalities that are only available with the T.S.A.M
>> >(map, alarms ...) ?
>> You got it.
Wait, this version doesn't seem to support alarms. TERMINAL_SERVERS is
not one of the entities that GETEVENT seems to support. Could you
please clarify ?? Thanks
Raja
|
| 630.14 | Alarms, not events? | TOOK::R_SPENCE | Nets don't fail me now... | Fri Feb 14 1992 17:36 | 4 |
| Alarms are certainly supported. Events may not be since (at least what
my foggy recollections says) terminal servers don't generate events.
s/rob
|
| 630.15 | Alarms & tsam | TOOK::FONSECA | I heard it through the Grapevine... | Tue Feb 18 1992 10:19 | 11 |
| As far as I know, alarms are supported by TSAM, learning more about Alarms
is one of the tasks I hope to accomplish this week so that I can be more
responsive to Alarms questions.
Please continue further discussion of TSAM in Note 2319 or create new notes,
this note is left over from a previous 'life' of TSAM and is mis-named to boot,
as there is no "TSM AM", it makes this note a bit difficult to find.
I'll try to get it renamed & closed.
Thanks,
Dave
|