Conference azur::mcc

Hello,

Developing our AM's (AIRCO and PABX) we use the mcc desframe routines, they
are described in the Management Module Programming Manual.


There are the following mcc_desframe routines available for memory management:

- mcc_desframe_init_alloc_list(...);
	Initialize memory management service.
- mcc_desframe_alloc(...);
	Allocate a buffer of free memory.
- mcc_desframe_create_descriptor(...);
	Allocate a MCC descriptor.
- mcc_desframe_free_alloc_list(...);
	Free allocated memory.


I hope you can use this.


Henk van Steeg
(Telecom & Networks 
 Utrecht, Holland)

>
>
>There are the following mcc_desframe routines available for memory management:
>
>- mcc_desframe_init_alloc_list(...);
>        Initialize memory management service.
>- mcc_desframe_alloc(...);
>        Allocate a buffer of free memory.
>- mcc_desframe_create_descriptor(...);
>        Allocate a MCC descriptor.
>- mcc_desframe_free_alloc_list(...);
>        Free allocated memory.
>
>
>I hope you can use this.
>

No. These routines are only useful when you do the allocation yourself. 

Here, in fact you fall into the very special case where mcc_ilv_get will always
allocate memory for you.

The response in fact is quite easy : mcc_ilv_get will return you an MCC_A_AES
structure as mcc_a_pointer field of your MCC descriptor (obtained by some kind
of mcc_aes_create call). So to free your memory just use mcc_aes_delete :

	mcc_aes_delete ( &desc.mcc_a_pointer )

Regards

Pierre.

re: .0

>    ValueDesc.mcc_w_maxstrlen = 0;
>    ValueDesc.mcc_b_dtype     = DSC_K_DTYPE_T;
>    ValueDesc.mcc_b_class     = DSC_K_CLASS_D;
>    ValueDesc.mcc_a_pointer   = MCC_K_NULL_PTR;
>    ValueDesc.mcc_w_curlen    = 0;
>    ValueDesc.mcc_l_dt        = MCC_K_DT_FULL_ENTITY;
>
> If you set it to a static descriptor with a pointer to a buffer allocated by
> your program, then mcc_ilv_get will return status MCC_S_INV_DESC, Invalid
> string descriptor encountered.
>

also be sure to set:

     ValueDesc.mcc_a_link      = MCC_K_NULL_PTR;
     ValueDesc.mcc_b_flags     = 0;

I don't know why the ILV get gave you an error if you used a Static
Descriptor .. ie, ValueDesc.mcc_b_class = DSC_K_CLASS_S .. It has
always worked for me.

------

fwiw - I was helping someone that couldn't get Alarm Rules to work with
their Management Module.  It turned out that when they built their Out-Entity
argument (they couldn't just copy In-Entity to Out-Entity) they had set
the Instance Descriptor mcc_b_flags field to MCC_M_FLAGS_DEFAULT (ie, 1).

The Alarms Rule Engine must ILV encode the Out-Entity to pass across
the DECmcc Call Interface.  When Out-Entity was ILV decoded, it was all
messed up (had no instance value).

The mcc_b_flags field is set when you ILV encode data; the data has no value.
When the data is ILV decoded, a status is returned which indicates there
is no value, and your decoding routine should assume the 'default value'
for the argument.

/keith

Thank you, guys.

Keith,

>also be sure to set:
>
>     ValueDesc.mcc_a_link      = MCC_K_NULL_PTR;
>     ValueDesc.mcc_b_flags     = 0;

Yes, I did, I have simply omitted it in my question.

You have mentioned mcc_b_flags. What is that? How should I use it?

Thank you,
Gene

P.S. It is really very annoying that in SRM there is no description for
MCC_T_Descriptor and its fields anywhere.

Maybe for the next release of SRM we invent supper-dupper structure which will
cover everything? It is so convenient to describe all mcc_... function just
with the single parameter and let users to figure out the rest.

RE: .4

>> You have mentioned mcc_b_flags. What is that? How should I use it?

I know of only one use for the MCC Descriptor mcc_b_flags field.

To best explain its use, I'll give an example...

Your Management Specification says that for an Action directive (like Create)
you have arguments - and you define one of your arguments as taking
a default value and being required.

If you enter the create directive to the FCL, and do not supply any value
for this argument, the FCL *will* pass you an argument anyway.  When
the argument is built by the FCL (ILV encoded into IN-P), the descriptor
mcc_b_flags field is set to MCC_M_FLAGS_DEFAULT -- (otherwise this field
will be set to zero).

When you ILV decode this argument from In-P , you get back a status from ILV:

	MCC_S_ILVIMPLDEFAULT

This is a signal to your Management Module that *you* should determine
the default value for the argument -- this would typically be accomplished
by going to the Dictionary, although your MM could have the value hardcoded
within.

Hope this helps

/keith

RE:  .4

P.S. It is really very annoying that in SRM there is no description for
MCC_T_Descriptor and its fields anywhere.

Maybe for the next release of SRM we invent supper-dupper structure which will
cover everything? It is so convenient to describe all mcc_... function just
with the single parameter and let users to figure out the rest.

kjn>>  If you look in Section 9.6 of the SRM  (page 283), there is a 
kjn>>  description of the MCC_T_Descriptor data structure.

...kjn

RE: -.1

  kjn>>  If you look in Section 9.6 of the SRM  (page 283), there is a
  kjn>>  description of the MCC_T_Descriptor data structure

  Kathy:

    Yes, there is one page in the SRM and thanks for pointing it out, but 
    the field descriptions in this section are extremely brief (all less than
    one sentence long).  There is not enough info there at all!

    Also, the SRM doesn't describe how the MCC descriptor is used for 
    particular arguments of particular calls to common routines.

    I know that the usage is similar for most calls, but this common usage
    should be described in section 9.6 and exceptions to the common usage
    should be described under the argument for each common routine.

    I think the SRM needs a "little" work in this area.  If I had a few free
    moments I could write up exactly what I felt was missing, but now is a bad
    time for me.  :( 

                                                                       - Jerry