| 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 |
As clearly stated in the SRM, the OUT-ENTITY parameter on an MCC-CALL must be handled as follows: If a NULL address is passed, the service provider can ignore out_entity unless it is handling a wildcard operation, in which case it must return MCC_S_NOOUT_ENT to tell the caller that the parameter is required in this case. If a non-NULL address is passed, the service provide MUST write into that address the address of a full AES describing the current entity. If wildcarding is not in effect, a simple AES_COPY from in-entity to out-entity is all that's required. It appears that the FCL is "helping" some MMs out by copying in-e to out-e before the mcc_call. This breaks distributed MCC (Ultrix now, VMS later) - since out-e is an rpc OUTPUT parameter, it is moved from service provider to caller, and NOT vice-versa. This causes the FCL's "favor" to turn into a memory leak as the address of the AES it has erroneously setup gets overwritten by the service provider's AES. I am going to QAR the FCL to remove this in the next 1.1 build thus exposing any any MM "cheaters". Be warned!
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 371.1 | INFO - not so fast.... | GOSTE::CALLANDER | Tue Oct 02 1990 16:55 | 7 | |
There are first a few considerations that must be taken before this
"helpful hand" can be removed. We must determine if any asynch release
modules will be broken (like SNMP AM), and what the impact to the
toolkit manuals/sample/yourmm and third parties will be.
This simple change will impact all MM's.
| |||||
| 371.2 | moi? | MKNME::DANIELE | Tue Oct 02 1990 18:13 | 12 | |
> We must determine if any asynch release modules will be broken > (like SNMP AM), ... Jill, I'm aghast! To think, even for a moment, that the SNMP AM isn't strictly adherent to the SRM! How could you? Actually, I copy in_entity to out_entity on every request, then fix up out_entity in the case of wildcards. So it sounds like SNMP will be OK. Mike ( PS, I was really waiting for the "most annoying global entity" award the other night. ) | |||||
| 371.3 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Wed Oct 03 1990 09:20 | 3 | |
The longer we wait the MORE mm's we'll be stuck supporting with the old
interface. We MUST clean up stuff like this now while we have some
semblance of control over the mm's that are out there.
| |||||