| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2250.1 | Remote Console! | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Mon Feb 03 1992 10:54 | 20 |
| Both TS AM and Ethernet AM use the Remote Console protocol type.
The protocol type is acquired/shared using protocol/address pair.
The MCC_EA routines provide locks to allow queueing of requests using
the same protocol/address pair, but TS AM doesn't use the MCC_EA routines
(and doesn't use our lock scheme).
Summary:
1. Short term : the two AMs will not interoperate
2. Medium term: TS AM should add our lock code.
Suggestion:
The TS AM developer(s) should acquire (from MCC_EA developer -
Vince YAZ8::Guarino) MCC_EA lock code and incorporate it in
TS AM.
Chris Brienen
|
| 2250.2 | Can't we share it? | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Mon Feb 03 1992 12:05 | 16 |
| Chris,
Couldn't the two AMs both use the Remote Console protocol at once by both
agreeing not to get an EXCLUSIVE lock on the protocol? This has been the
problem with Ethernim and TSM for years, and I have pointed out to those
developers how to get the protocol in "shared" mode instead of exclusive.
Since they were not doing any further development, that change never got into
their code, but I did ask that any AMs get the protocol shared so that we
wouldn't bump into each other like this.
Or is this not the sme problem? Remember, I haven't been in this code for a
while!
Thanks
- Linda
|
| 2250.3 | Not possible... | CHRISB::BRIENEN | DECmcc Bridge|Station|SNMP Management. | Mon Feb 03 1992 14:17 | 21 |
| Hi Linda,
I don't believe we're using the word "EXCLUSIVE" in the same way...
As long as TS AM and Ethernet AM are talking to DIFFERENT ADDRESSES,
or using DIFFERENT PROTOCOLS, or using DIFFERENT CONTROLLERS, there is
no "conflict" (both using Shared-with-destination, right?; lock created
by the MCC_EA Routines use PROTOCOL|ADDRESS|CONTROLLER).
The problem comes when two processes/threads/whatever attempt to
use the same ethernet protocol type (remote console) to access the same
target address (e.g., terminal server) : which process/thread/whatever does
the ethernet driver give return packets from that address? It has to use
something to decide this (addr or protocol type)...
DECmcc (the MCC_EA Routines) uses locks to queue access to the driver
in the case where there's a conflict.
Doesn't seem like adding the lock code would be that big of a deal...
Chris
|
| 2250.4 | got it | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Tue Feb 04 1992 10:19 | 10 |
| Hi Chris,
Okay, I see what you mean. Good, I didn't want to see that same old protocol
sharing thing come up again. I will ask the TSAM developers to contact Vince
Guarino if they haven't already. Since you say it's not difficult, maybe they
can add it in time for SSB.
Thanks for clarifying
- Linda
|
| 2250.5 | Talking to different addresses | SNOC01::MISNETWORK | They call me LAT | Wed Feb 05 1992 22:05 | 12 |
| re .3
>>> As long as TS AM and Ethernet AM are talking to DIFFERENT ADDRESSES,
>>> or using DIFFERENT PROTOCOLS, or using DIFFERENT CONTROLLERS, there is
>>> no "conflict"
Then why when I try using an alarm via the Ethernet AM on one address ( a PDP )
does my terminal server alarm using TS AM die when it is looking at another
address ?? If I understand correctly, both should be able to work at the same
time.
Cheers,
Louis
|
| 2250.6 | | TOOK::FONSECA | I heard it through the Grapevine... | Wed Feb 12 1992 10:49 | 7 |
| The reason is that the Ethernet AM and the Terminal_server AM share
the same address on the host end. If you have alarms set on one
or both, and the response for the Ethernet AM comes back, but is
recieved by the Terminal Server AM (since they are resident on the same
node, (and same process?)) things are bound not to work.
-Dave
|