Conference azur::mcc

I forgot to say something.

In the end_directive() after the mcc_desframe_set_cvr_and_reply(...) 
routine the status is MCC_S_ILVTOOBIG.

And this is when the AM is called for the second time (with a big enough
out_p buffer).


Henk. 

    Support for Insufficient Buffer Space is one of the most confusing
    algorithms described in the SRM.  It is sufficiently vague and
    sparse to cause almost anyone to implement it wrong.  Here is
    my interpretation:
    
    It sounds like it may be a bug in AM.  There are two ways of handling
    insufficient buffer problems:
    
    1)  If the descriptor is Class D, the Service Provider (e.g., the AM)
        can resize the buffer and change mcc_w_maxstrlen, mcc_w_curlen,
        and mcc_a_pointer fields in the out_p buffer.  The Client (who
        has stated it is a Class D Descriptor) is responsible for Freeing
        the buffer.
    
    2)  The Service Provider cannot support resizing the output buffer.
        This happens if the Client passes in a Class S descriptor.  Or
        if the Service Provider does not support Class D descriptors.
        Although the Service Provider has a choice of supporting Class D
        or not, there are two problems with this:
              1)  It may not be supported in the SRM  (I think it only
                  documents that if it is Class D the Service Provider
                  MUST support it).
              2)  It is possibly there is even more code NOT to support
                  it.  Which will be described further down.
    
        2.1) The amount of needed buffer space is placed in the mcc_w_curlen
             field, and a CVR of MCC_S_INSUF_BUF is returned through the call
             interface.
        2.2) Should the handle be set to MORE or not??  In general, the
             Service Provider should set the handle to MORE.  In fact,
             the handle may already have been set to MORE by a previous
             call.  If it is already MORE, it must remain MORE.  If it
             is FIRST, the Service Provider has a choice.  It may
             give up and leave the handle alone and return the CVR,
             or it may save the data in it's local memory and return
             MORE to copy it out.  If the handle is left alone (handle
             state stays at FIRST), then the operation is consider
             "completed with error".  If the handle state goes from
             FIRST to MORE it means "incomplete -- please resize and
             call back (and ignore all other output parameters)".  The
             description of this behavior is scattered thoroughout the
             SRM, but see page 324 for a brief description of
             MCC_S_INSUF_BUF processing.
        2.3) It's also important the the Service Provider check the
             handle state before validating Out_P.  If the handle
             state is Cancel, Out_P should not be validated (it is
             acceptable for the Client to pass in an empty Out_P
             for Cancelling). 
        2.4) If the Client sees a handle of FIRST and a CVR of
             MCC_S_INSUF_BUF, then it DOES NOT HAVE TO CALL BACK.
             If the Client sees a handle of MORE it MUST ALWAYS CALL
             BACK.  Even if it is just to Cancel the operation.
    
    What is the Handle state when you get MCC_S_INSUF_BUF, is it MORE or
    FIRST?  And which AM is it?
    
    -Matt.
    

  Henk,

  (Q) Did you write this AM?

  (Q) Did you write an FM that is calling another AM?

  (Q) Are you using the v1.2 Toolkit YOURMM?

  There have been some bug fixes the the Design Framework and YOURMM code
  which should make the INSUFBUF problem transparent to you.  I suggest that
  if you haven't already, please look over the new YOURMM source code.

  We apologize for making changes to the YOURMM source code, but they were
  bug fixes.  You should make these same changes to your MM.

  In the future, the Toolkit team would like to adopt C++ techniques which
  allow the ugly details of the Call Protocol to be hidden from the developer.

  /keith


  >>> From the Design Framework SET_CVR_AND_REPLY routine:

  *  This routine will process the Reply Table and construct Out_P, which
  *  will contain an the Reply.  The Reply Table is accessed via the
  *  the Reply-Index, which identifies which reply to return.  The CVR,
  *  response or exception, is returned via the CVR parameter.
  *
  *  The Reply is built in the Caller's Out-P buffer directly.  If the
  *  descriptor type is 'Dynamic' the buffer may be reallocated dynamically
  *  by the ILV routines - transparently to this routine  8)
  *
  *  If ILV returns MCC_S_ILVTOOBIG, then Out-P wasn't large enough - we
  *  don't know how big it should be.  When this happens, the DECmcc Call
  *  protocol requires that the Out-P descriptor 'curlen' field be set to
  *  the actual byte-count requred, and the MCC_S_INSUF_BUF status returned.
  *
  *  Whereas we don't know how much space is required, we'll ask for twice
  *  the space (ie, curlen = maxstrlen * 2).  The Local Context 'more_data'
  *  flag is set to TRUE - which will cause the Call context to be saved.



  >>> From the YOURMM source code; init_handle_more routine

  *  ------------------- Process INSUF_BUF status ------------------------
  *
  *  Continue re-initializing the Local Context Block
  *    o  Set the Reply-index to undefined ...
  *
  *  ... If the 'last-status' (status returned from the previous
  *  call) was *not* INSUFBUF_OUT_P - then the 'reply-index' can
  *  be set to undefined and a Normal status returned.
  *
  *  If the 'last-status' *was* INSUFBUF_OUT_P, then we want to
  *  return that status, skipping the 'do-directive' code and going
  *  directly to 'end-directive'.
  *
  *  The INSUFBUF_OUT_P status indicates that the previous call
  *  could not complete because the Callers Out-P buffer was too
  *  small - by now, they should have increased the buffer size,
  *  and we can proceed to building Out-P again.  Leaving the
  *  Reply-index value as it was set before enables us to remember
  *  which reply was being built.
  *
  *  If we have a BAD status,
  *    Set the reply_index to DFW_K_REPLY_UNDEFINED (DFW -> design framework).
  *    This will allow the bad status to be reported to the calling management
  *    module.

Matt,

Would you, please, elaborate on the following:

>    1)  If the descriptor is Class D, the Service Provider (e.g., the AM)
>        can resize the buffer and change mcc_w_maxstrlen, mcc_w_curlen,
>        and mcc_a_pointer fields in the out_p buffer.  The Client (who
>        has stated it is a Class D Descriptor) is responsible for Freeing
>        the buffer.

As I have mention in the note 2431 the FCL calls out module with the following
descriptor:

    mcc_w_maxstrlen:    1024
    mcc_b_dtype:        14
    mcc_b_class:        2
    mcc_a_pointer:      2138060
    mcc_w_curlen:       0
    mcc_b_flags:        0
    mcc_b_ver:  1
    mcc_l_id:   0
    mcc_l_dt:   127
    mcc_a_link: 0

Does it mean that if our module need to output more then 1024 bytes, we simply
trough away the value of mcc_a_pointer and put there our own? How should we
allocate this NEW buffer? How our client - FCL in this case - will be able to
free this NEW buffer? Does FCL have to store the value of the mcc_a_pointer
before calling our module, so that it will be able to free this ORIGINAL buffer
after return from our module?

Thank you for your answers,

Gene

Hi

Thanks for your quick and good answers.

- I am writing this AM, it is a part of the PABX AM. I am developing now the
	PABX accounting part, the PABX alarming part is ready.
- I am using DECmcc V1.1 with the toolkit V1.1

More info:
- I give the following command:
	SHOW PABX .TC_UTO PABX_ACCOUNTING EXTENSION 3320 OUTGOING ALL STATUS
- Then the PM calls my AM.
- The AM returns to the PM:
	status = MCC_S_INSUF_BUF
	out_p->mcc_w_curlen = 2856
	handle = MORE
- The PM calls for the second time my AM:
	out_p->mcc_w_maxstrlen = 2856
- The AM makes now the ilv list (with mcc_ilv... routines) using
	(*p_context)->ReplyArg_p1 (with a total length that is smaller than
	the value in mcc_w_maxstrlen (2856) )
- In the end_directive() the routine mcc_desframe_set_cvr_and_reply is called.
  	This routine returns with MCC_S_ILVTOOBIG status.

Why does it return this status (the list is smaller than the space that is
available) ?


Regards Henk

    RE: .4
    
       Read the routine description of the mcc_call -- Page 508 on Out_P. 
    For Class D only, the Service Provider should call lib$sget1_dd() to
    re-size the buffer.  This usage of VMS routines is not portable, and
    frankly, is pretty gross.  On ultrix, you are supposed to include the
    file mcc_descrip.h which redefined the lib$ string routines into their
    mcc equivalents.  FCL (the client of the call) is responsible for
    freeing the memory by ultimately calling lib$sfree1_dd.
    
    RE: .5
    
       Yes, the buffer is too small to hold the ILV encoding (or if you
    look at it in a mirror, the ILV encoding is too big to fit into the
    buffer).  That message has always confused me.
    
    -Matt.

re: .5

> - I am using DECmcc V1.1 with the toolkit V1.1

  You might want to try linking with the v1.2 MCC_DESFRAME.OLB file.
  Do you have access to a system running DECmcc t1.2.x ?  or I can copy
  the file to your system.


> - I give the following command:
> 	SHOW PABX .TC_UTO PABX_ACCOUNTING EXTENSION 3320 OUTGOING ALL STATUS
> - Then the PM calls my AM.
> - The AM returns to the PM:
>	status = MCC_S_INSUF_BUF
>	out_p->mcc_w_curlen = 2856
>	handle = MORE
> - The PM calls for the second time my AM:
> 	out_p->mcc_w_maxstrlen = 2856
> - The AM makes now the ilv list (with mcc_ilv... routines) using
> 	(*p_context)->ReplyArg_p1 (with a total length that is smaller than
> 	the value in mcc_w_maxstrlen (2856) )
> - In the end_directive() the routine mcc_desframe_set_cvr_and_reply is called.
>   	This routine returns with MCC_S_ILVTOOBIG status.
>
> Why does it return this status (the list is smaller than the space that is
> available) ?

  (Q) Who determines that 'out_p->mcc_w_curlen' should be set to 2856 ?
      Is it your code, or the Design Framework?

   After you encode your response data and call the SET-CVR-AND-REPLY routine,
   other data is combined (reply id, and argument id) to form the complete
   response.

   However the 2856 is getting determined, add 500 to it before returning
   the INSUF_BUF status to the PM.

  /keith

re: .7

I determine by myself how big 'out_p->mcc_w_curlen' should be.

I tried 'out_p->mcc_w_curlen = 25000' but also mcc_desframe_set_cvr_and_reply()
returned MCC_S_ILVTOOBIG.

Henk.

re: .9

> I determine by myself how big 'out_p->mcc_w_curlen' should be.
>
> I tried 'out_p->mcc_w_curlen = 25000' but also mcc_desframe_set_cvr_and_reply()
> returned MCC_S_ILVTOOBIG.

  Henk,

  Does this mean that you set 'out_p->mcc_w_curlen' to 25000 ... then called
  set-cvr-and-reply ?  You can't do that.  The caller allocated Out-P and unless
  Out-P is defined as dynamic you are not allowed to change the descriptor
  'maxstrlen' or 'pointer' fields ... or set 'curlen' to a value larger than
  'maxstrlen'.

  If you did just change curlen then called set-cvr-and-reply, Your reply
  would be ILV encoded as usual.  The ILV routines would keep an eye on the
  'maxstrlen' value and only allow you to encode up to that point.

  If you changed curlen *after* set-cvr-and-reply returned you the ILVTOOBIG
  error and returned to the caller the INSUF_BUF cvr, then the caller should
  have increased the Out-P buffer to 25000.

  -----

  As I said before, all this logic is just too complex.  Computers were
  designed to make your life simpler, not more complex.  Please look at the
  new v1.2 toolkit.

  There were some bugs in the logic in the YOURMM template and Design Framework
  code.  I strongly suggest that you look at YOURMM and modify your code
  accordingly.  Do you have access to the v1.2 toolkit ?  You should try
  linking with the new MCC_DESFRAME.OLD & MCC_DESFRAME.H files.

  /keith