| 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 |
Is it possible to return a buffer greater than 1024 bytes from the AM.
Currently the out_p descriptor that is passed to the AM is set for 1024 bytes
and potentialy we need to send back more than that. Is there any way to do it?
Also a suggestion for the templates that are supplied. In the end_directive()
routine currently the code reads.
----------------------------------------------------
{
cvr = *p_status;
status = mcc_desframe_set_cvr_and_reply(p_callargs,p_context, &cvr);
}
status = update_call_handle(p_callargs, p_context);
----------------------------------------------------------------
If the set_cvr_and_reply returns an error the status is not checked and
returned to produce an MCC error, if the buffer is too big
update_call_handle return success and the AM completes successfully
with no response.
Graham.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 760.1 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Feb 28 1991 08:47 | 10 | |
This is a crock we need to fix some day.
At the moment, if out_p is too small, have the AM put the size it
really needs into mcc_w_curlen in the out_p descriptor and return
with an MCC_S_INSUFFBUF_OUTP status (not an exception). The caller
will call you back with the right size buffer.
The correct way is to support dynamic descriptors in out_p - it's on
the list.
| |||||
| 760.2 | you get a choice of crocks | TOOK::GUERTIN | E = mcc | Thu Feb 28 1991 09:06 | 18 |
Actually, I think there are two ways to handle this situation. The
first is as Jim Swist mentioned. Although, according to the SRM you
must set the handle state to MORE if you return MCC_S_INSUF_BUF (SRM
section 10.5.9, page 319), that really does not make a lot of sense on
the very first call, but just to be safe (and SRM compliant), I suggest
you always set the handle to MORE if you take this approach.
The second approach is SRM legal, but has its critics. Mainly because
it is platform dependent. If you are on VMS, AND the client has passed
down a CLASS D descriptor, then you are guaranteed that the string was
allocated with the LIB$SGET1_DD run-time-library routine (SRM chapter
11, page 508), and you can use the same routine for re-allocation,
(noting that the mcc_w_curlen field must be updated to reflect the
actual length). On ULTRIX, I assume you are allowed to free and
re/m/c-alloc the mcc_a_pointer field (Jim Swist would know the answer
to this). Note again, this is ONLY if the descriptor class is D.
-Matt.
| |||||
| 760.3 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Feb 28 1991 09:18 | 8 | |
The descriptor won't be class D if your AM is called by any of the
MCC-supplied FMs/PMs. Also, class D descriptors don't work across
the RPC interface so you are guaranteed to break on Ultrix if you
use them.
I'd stick with workaround #1 until we do domething about dynamic
descriptors.
| |||||
| 760.4 | MINDER::BLOWERG | Thu Feb 28 1991 17:14 | 2 | ||
Thanks,
We have to go to ultrix shortly so I'll Stick with #1.
| |||||
| 760.5 | must have handle to MORE | GOSTE::CALLANDER | Fri Mar 01 1991 17:03 | 3 | |
BTW: the note to set the handle to MORE is not just to be compliant,
if you don't do it both PMs will *NOT* call you back.
| |||||