| 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 |
Does anyone know how the MOP channel problem can be dealt with for users who want to run multiple access modules like TSM and DECelms and DCM? My understanding is that DECelms consumes the channel and won't share. I understand the product directions with regard to new AM's, but specifically will this problem be addressed? regards
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1248.1 | Good question... | TOOK::W_MCGRATH | DTN 226-5075 | Thu Jul 18 1991 12:42 | 17 |
My understanding is that DECelms opens the channel in exclusive mode,
locking out TSM, ETHERnim, and any other user of the MOP protocol.
It could use shared-default mode for it's function of locating bridges.
That would probably be best. It still would conflict with ETHERnim's
Listen-for-SYSID function (but not necessarily its REQID/SYSID function).
We staged some intial meetings and sent some mail to DECelms developers
when they were first getting ready to implement their bridge-recognizing
function, but the decision was to document around the problem. The
problem is also documented in the TSM V1.4 release notes.
I've also heard of some MCC-ETHERnim problems documented in MCC's
release notes.
I would talk with the DECelms Product Manager (Mark Collett).
-Will-
| |||||