| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3280.1 | Maybe Callable-TSM requires it? | MOLAR::BRIENEN | DECmcc LAN and SNMP Stuff... | Fri Jul 03 1992 14:02 | 1 |
|
|
| 3280.2 | PRMMBX | TOOK::CASSIDY | Linda, LKG2-2/BB10, DTN 226-7270 | Mon Jul 06 1992 10:28 | 6 |
| TSAM needs to set up mailbox communication between MCC and a process that uses
callable TSM. TSAM starts up this "server process" when you first enable TSAM
and then every TSAM command sends a command to the process via the mailbox. And
yes, I think this is the way it is going to ship.
- Linda
|
| 3280.3 | | TOOK::FONSECA | I heard it through the Grapevine... | Mon Jul 06 1992 11:31 | 8 |
| Thanks Linda!
Yes, TSAM will be shipping this way. The intention is that the mail box
be permanent, so even if the original process which ENABLEd or started up the
datached process went away, the detached process and the mail box would
still be around for other DECmcc users.
-Dave
|
| 3280.4 | Still confused...
| WELTM1::CRIDDLE | Graham Criddle, DS Tech Consultant, 853-4015 | Mon Jul 06 1992 13:03 | 23 |
| Hi, all...
Thanks for the replies...
I still don't understand.
I firstly don't see why a permanent mailbox is needed - as I assume that the
terminal server detached process needs to be present for TS access to take place.
If this is true then a temporary mailbox is sufficient, created by the detached
process.
Even if this is not the case, and a permanent mailbox is needed, why does a
standard MCC user need this privilege as a non-priviliged user can assign a
channel to a permanent mailbox.
Rgds,
Graham
PS. The reason I am interested in this is that we are currently implementing an
NMS system on one of our major customer sites and want to use the TSAM module
when we upgrade to 1.2 SSB later this year.
They will not be keen on granting the PRMMBX privilege to anyone!!!
|
| 3280.5 | | TOOK::FONSECA | I heard it through the Grapevine... | Mon Jul 06 1992 16:45 | 6 |
| You're right. The way you describe is the way I thought it worked.
It looks like the code attempts to create a permanent mbx *every* time.
I'll look in to changing the way we assign a channel to the mail box, but
I won't promise for this release, we are very close to SSB at this point.
-Dave
|
| 3280.6 | Permanent mailboxes are never needed! | MARVIN::COBB | Graham R. Cobb (DECNIS development), REO2-G/G9, 830-3917 | Fri Jul 17 1992 08:56 | 15 |
| Note that on VMS "temporary" mailboxes stay around as long as *either* side
has a channel assigned (more correctly as long as any process has a channel
assigned to it). In practice, permanent mailboxes are never needed on VMS
(and are usually not desired because you want the mailbox to go away if the
server goes away).
The most common (and incorrect!) reason for people using permanent mailboxes
is that the mailbox logical name gets stored in the system table and so is
visible to the other process. That is using a sledgehammer to crack a nut!
The best solution depends on exactly how your processes need to interact.
Unfortunately, in most cases some form of elevated privilege is needed but
you may be able to make the server do the privileged work.
Graham
|