Conference azur::mcc

RE: .1

>1. The PMs will be passing CLASS_D (dynamic) descriptors for out-p.
>   If your validation routines check the class of the descriptor (they
>   probably shouldn't) you may be affected.  

Thanks for the info Pete. I'm using the Design Framework validation stuff,
which does check the class of the out_p descriptor. I'll get it disabled
before I try to run on the first V1.2 baselevel.

RE: .1

>1. The PMs will be passing CLASS_D (dynamic) descriptors for out-p.
>   If your validation routines check the class of the descriptor (they
>   probably shouldn't) you may be affected.  

	Doesn't the SRM state that the AM *must* check this class, in order
	to implement the prescribed algorithm when Out_P is too small?

	Doesn't that algorithm specify that the AM reallocate the Out_P
	buffer if it is dynamic?

pg 46 of SRM V1.1, section 4.3.2.1 (I'm not making it up!) says:

       "Buffers for output data are pointed to by MCC descriptors.
        The descriptor is either of the static or dynamic class."

pg 508 of the SRM gives notes on the lib$sxxx routines that must be used on VMS
       to manipulate dynamic memory

as far as who allocates, the SRM says:

(pg 46) "It is the responsibility of the client to allocate and initialize
         all of the parameters and to deallocate them after use."

The exception being, of course, dynamic memory:

(pg 509) "If the class is DSC_K_CLASS_D (dynamically allocated), the service 
          provider may return, to the heap, the buffer pointed to by the
          descriptor; it will then allocated a new buffer..."

The key in the above paragraph is "MAY RETURN", i.e. you can still
return MCC_S_INSUFBUF even if the descriptor is class D and have the
client re-allocate for you.  It's just less efficient.

but!

I know we've got MMs in-house that will break when FCL or IMPM passes down
a dynamic descriptor.  I just ran one today.  And the design framework generally
chokes on them (see .1).

We're going to have to either work-around the fact that we need to be backward
compatible with MMs who reject class D descriptors or just back off using
class D altogether.

looks like it'll be more work to try to use class D descriptors than it's worth,
what with some existing MMs (potentially anything using the design framework) 
rejecting them.

Forget it.

    If the design framework is in violation of the SRM it should be QARed.
    This means that most third party vendors are going to code it wrong.
    
    -Matt.

    
    Just because "doing it right" might be a pain now, doing it right later
    may be even more painful (You can pay me now, or you can pay me layer). 
    I have had the pleasure 8-) of having to deal with INSUFBUF errors. 
    They only are recognized while building a large OUT_P (larger the 1024
    bytes when I was doing it).  Knowing this caused me to have to save all
    information I was parsing until OUT_P was completely built.  If I got
    the OUT_P error, I had to do all sorts of kludgy processing to get a
    larger buffer (and sometimes the larger buffer was too small).
    
    Any MM which checks the CLASS of the OUT_P descriptor, gets what it
    deserves (there is no need what so ever to check this field), this
    includes the design framework (fix it).  Any MM which relies on the
    POINTER to not change, should use static descriptors or change its
    behaviour with dynamic descriptors.  It is this engineers opinion that
    changing OUT_P to be DYNAMIC is the right way to go.
    
    Who put that soapbox under me???
    
    ~Jon.

But a less than robust usage of the design framework.

You can set up your df validation routines to accept either D or S, as follows:
(thanks Anwar -> Darryl -> Keith)

static dt_valid_outp           valid_out_p        = 
       { CAV_V_DESC_STATIC | CAV_V_DESC_DYNAMIC };

However, given local experience (and one "external" - R. Kittell), most people's
MMs aren't coded that way.  So it doesn't really change the backward 
compatibility issue.

It would be good if our example usage of the design framework (both on-line
and documentation) used this new approach.

re: .6

I never said I'm not doing this because it's a pain.

I have a schedule, with little additional time for fixing things that aren't 
really broken.

The reason I was changing to class D was to work around a problem encountered
on ultrix.  When it became apparrent that it would require significantly more
work to support both S and D for existing MMs that don't like D's, we instead
fixed the problem on ultrix (much less work) that we were using the D's to work 
around.

>   Any MM which checks the CLASS of the OUT_P descriptor, gets what it deserves

To do the "right thing" while using dynamic descriptors, the PMs (and any MMs 
that care to remain backward compatible with MMs developed using *OUR* code and
*OUR* examples) must jump through a few hoops if they choose to use class D
descriptors.  

If you're supporting a PM/MM and have the time, fine.  I don't.  Sorry.

>static dt_valid_outp           valid_out_p        = 
>       { CAV_V_DESC_STATIC | CAV_V_DESC_DYNAMIC };
>
>However, given local experience (and one "external" - R. Kittell), most people's

I haven't shipped yet, so no problem changing it. The code is right out of
the sample stuff, so you want to make sure it it gets fixed there. Also,
the "writing a MM" doc needs to indicate you can OR those values. That
was the first place I checked when you raised the issue, and since it
didn't indicate I could get it to accept either value I disabled the check.

    The DECmcc Toolkit team got together this morning and discussed Dynamic
    Descriptors.  As a result we'd like to share our thoughts.


    >>> Point # 1

    RE: .3

    >> (pg 509) "If the class is DSC_K_CLASS_D (dynamically allocated), the
    >> service provider may return, to the heap, the buffer pointed to by the
    >> descriptor; it will then allocated a new buffer..."

    >> The key in the above paragraph is "MAY RETURN", i.e. you can still
    >> return MCC_S_INSUF_BUF even if the descriptor is class D and have the
    >> client re-allocate for you.  It's just less efficient.

    If you support Dynamic Descriptors and Out-P is too small, then you
    should reallocate the buffer and continue.

    If you support Static Descriptors and Out-P is too small, return
    MCC_S_INSUF_BUF and set the mcc_w_curlen field to the number of bytes
    you need.

    We don't believe that the key word here is "MAY RETURN" - its one or the
    other; Static or Dynamic.


    >>> Point # 2

    If you choose to allow MCC Dynamic Descriptors in your MM for Out-P,
    you'll need to write code to support them.  The VMS LIB$ routines for
    memory management are not recorded by the "FAKE-VM" tool;  FAKE-VM is
    used to detect memory leaks.  Memory leaks regarding Dynamic
    Descriptors would go undetected.  Also, consider the platform
    independence (VMS, Ultrix, ...).  MM's should be written with the least
    amount of O/S specific code as possible.

    MCC should provide routines which mimic the LIB$ routines functionality
    without the loss of detecting memory leaks.

                 <<< This needs to go to the MRG board >>>
                     <<< to work out the details >>>

    >>> Point # 3

    Q: What are we really trying to accomplish?
    A: If Out-P is too small - make it bigger so you can return your data.

    Q: Who told you Out-P was too small?
    A: The MCC ILV routines.

    Q: Then, where should the support for Dynamic Descriptors be?
    A: Dynamic Descriptor support should be a combination of MCC Memory
       routines (so that the memory leak detection still works), and
       the ILV routines that detect and reallocate the Descriptor Buffer
       as needed (provided it is a Dynamic Descriptor)

    Of course - ILV wouldn't reallocate Out-P one byte at a time.  It would
    grow 512 bytes at a time - or what ever seems reasonable.

    Your MM wouldn't even know this happened - it would all be transparent.


    >>> Point # 4

    Q: What should the Design Framework check for Out-P Class field?
    A: That the value is either DSC_K_CLASS_D or DSC_K_CLASS_S.  Any other
       value would be invalid.

    If this is acceptable to everyone - then the Design Framework will be
    changed for v1.2

RE: .10

Sounds real good. One additional place that may need to be checked would be
the mcc_desframe_set_cvr_and_reply routine. According to the documentation
on it, it builds the ILV in a temp buffer so it can tell whether
out_p is big enough. That can be taken out once the ILV routines handle it.


Richard

    RE: .11
    
    >> ... mcc_desframe_set_cvr_and_reply ...
    
    The reason that out-p is built in a temporary buffer is to determine
    the actual size needed for the encoding.  After the encoding is done,
    its size is compared with the real out-p buffer - and if it won't fit
    then the MCC_S_INSUF_BUF is returned.
    
    If Static descriptors can still be used then we need to execute this
    logic - but for Dynamic descriptors, you're right, out-p can be built
    in place and grow transparently as needed.
    
    /keith