Conference azur::mcc

The "NOENTITY" message is a generic (!) way to say that your out_p is
badly ILV encoded.

>    At this time the whole ILV response was encoded by the event sink
>    application. The event has 1 argument. The two constructions got the
>    MCC_K_ILV_LIST_VALUE modifiers. The call sequence was:

No. You should encode an event report in NATIVE mode.

>[  10 ] (
>    [  11 ] (
>        [  200 ] (
>            [  1 ]             00
>            [  3 ]             00
>            [  4 ] (
>                [  201 ] (
>                    [  1 ]                     03
>                    [  2 ]                     41 73 73 6f 63 69 61 74 65 64 20
>65 76 65 6e 74 20 64 61 74
>                    61  -- Associated event data
>                    [  3 ]                     00
>                    )
>                )
>            )
>        )
>    )

This is not correct. You should have (by simply changing the ILV mode to NATIVE)

[  10 ] (
    [  11 ] (
        [  200 ] (
                [  201 ]                     41 73 73 6f 63 69 61 74 65 64 20
65 76 65 6e 74 20 64 61 74
                    61  -- Associated event data
                )
            )
        )
    )

Another comment :

>           DIRECTIVE GETEVENT = 65:
>               DIRECTIVE-TYPE=EVENT,
>
>               RESPONSE getevent_success = 10:
>                  SYMBOL = geteventsuccess,
>                  TEXT = "UAF event received",
>                  ARGUMENT geteventrep = 11 : Event_Report
>                      SYMBOL = attr_getevent_rep
>                  END ARGUMENT geteventrep;
>               END RESPONSE getevent_success;
>
>            END DIRECTIVE getevent;

Your GETEVENT definition, even if it is correct, is not "standard" : a
standard GETEVENT will use 1 as id_code for both the response and event_report
id_codes. I do not know if it is a problem, but I think the NOTIF FM for
example is expecting this id_codes to be 1 (but maybe it does not check them,
simply doing ilv_get_id calls and discarding the actual value) when reading the
response.


>QUESTION 2.
>    Which is the preferred way to pass events to the AM ?  I see two
>    alternatives.  Either you prepare the whole argument in the event sink
>    application, and the AM passing it (without any additional processing) to
>    the caller (FM or PM).  Either you only pass the event_report as an
>    argument to the mcc_event_put routine, where as the AM will have to
>    encapsulate it with a mcc_ilv_put_param_begin/mcc_ilv_put_param_end
>    construct.  This will give the AM more control over the consistency of
>    the out_p argument. Can you tell which are the preferred ILV call
>    sequences at both the event-sink and event-report sides, e.g. for an
>    event report having 1 argument.
>    Is it also possible to send only the event_report construct in a mcc_event_put,
>which should then be encoded in a parameterlist in the AM ?
>

I have no definitive answer on that (I'll let the *real* MCC gurus answer),
but my opinion is that first you can only pass a simple (native) argument
through the event_put and so the only way to pass more than one argument
to the event_put is to ILV encode it. So, if you want to have your sink
consistent (if you have different events, some having more than one argument)
the better way to do it is directly put in the event_put call the out_p
of the GETEVENT directive. That's what we do, and that what everybody I know
does.

Hope this helps.

Regards.

Pierre.

    repl .1
    
>>> Your GETEVENT definition, even if it is correct, is not "standard" : a
>>> standard GETEVENT will use 1 as id_code for both the response and event_report
>>> id_codes. I do not know if it is a problem, but I think the NOTIF FM for
>>> example is expecting this id_codes to be 1 (but maybe it does not check them,
>>> simply doing ilv_get_id calls and discarding the actual value) when reading the
>>> response.
    
    This is certenly the problem.  I had the same problem before.
    The respponse and the argument, if it is an event-report, has to have
    the id-codes = 1.
    
    Look at note # 1529.2 where Jill Callander have posted the MS-def for 
    the GETEVENT-directive.  There you'll find what codes are wanted.
    
    Good luck,
    Nils

Another error, before reaching success...

Still the same MSL.
This time when I try to encode the ILV response, using two times a construction
with MCC_K_ILV_NATIVE_VALUE mode, I cannot do a mcc_event_put any more.
I receive the error :
	%MCC-E-ILV_BAD_MODE, ILV mode inconsistent with Arguments
Surprisingly the example on note 1360.*, where the same sequence is used,
seems to work.

	mcc_ilv_param_begin
	mcc_ilv_constr_begin	MCC_K_ILV_NATIVE_VALUE
	mcc_ilv_constr_begin	MCC_K_ILV_NATIVE_VALUE
	mcc_ilv_put
		%MCC-E-ILV_BAD_MODE, ILV mode inconsistent with Arguments
	mcc_ilv_constr_end
	mcc_ilv_constr_end
	mcc_ilv_param_end

The ILV_PUT use the following parameter:

        arg_length = strlen (event_data);

        arg_desc.mcc_w_maxstrlen = arg_length ;
        arg_desc.mcc_a_pointer = &event_data;
        arg_desc.mcc_w_curlen = arg_length;
        arg_desc.mcc_b_flags=0;
        arg_desc.mcc_b_ver = 1;
        arg_desc.mcc_b_dtype = DSC_K_DTYPE_T;
        arg_desc.mcc_b_class = DSC_K_CLASS_S;
        arg_desc.mcc_l_id = MCC_K_SPEC_EVENT_ARG;
        arg_desc.mcc_l_dt = MCC_K_DT_LATIN1STRING;
        arg_desc.mcc_a_link = MCC_K_NULL_PTR;

        stat = mcc_ilv_put ( &ILVctx,
                             &arg_desc,
                             &reason_code);
  
And, because of the error the ILV dump becomes:
ILV dump of OUT_P:

[  10 ] (
    [  11 ] (
        [  200 ] (
            )
        )
    )
instead of the one expected with argument 201.
Any idea about this ?
********************************************************************************
More comments on QUESTION 2.

If the event report can be seen as a construction (cfr SRM pg 279), where
the construction ID is the event code, and the data are the parameters in the
construction.  If there are no parameters to the event report, the event report
can be passed as an empty construction.  If there are parameters, there will be
as many mcc_ilv_puts as there are parameters.

I do not see any difficulty to pass a "naked" event-report with or without
arguments.

That whole event_report could then easily be put in a parameter list
	mcc_ilv_param_begin
	mcc_ilv_constr_begin
		mcc_ilv_copy_param from "naked" event_report
	mcc_ilv_constr_end
	mcc_ilv_param_end

The problem is, I encounter, that you cannot build a construction on its own,
e.g. for an complete event report, without being preceeded by a
mcc_ilv_param_begin.  THAT IS THE MAIN PROBLEM.
Therefore to extract that event-report construction, it will take several ILV
calls to position the ILV context on the right argument.

Ultimately, because of this, it seems easier to build the full argument
list already in the event sink application.
    
    Dominique.
    

>
>        stat = mcc_ilv_put ( &ILVctx,
>                             &arg_desc,
>                             &reason_code);
>  

Look at the SRM definition of mcc_ilv_put :

"If the current mode is NATIVE_VALUE, then the reason_code argument is not
applicable and MUST reference MCC_K_NULL_PTR"

So call instead :

        stat = mcc_ilv_put ( &ILVctx,
                             &arg_desc,
                             MCC_K_NULL_PTR);

which should fix the problem.

Regards.

Pierre.