Conference azur::mcc

Nils,

(1)
The SRM says that if the mcc_event_get routine is passed a MCC_K_NULL_PTR
for the 'event_filter' argument - any event code which occurs will be returned.

(2)
If you want to select a list of possible event codes you are interested in,
you build an array of longwords containing those event codes...the last long
word is a NULL.

(3)
Your 'getevent' directive must convert In-P from an ILV encoded list of
event codes, into an Event Filter list.  I'll post the code that can do
this in the next reply - this is taken from the Alarms FM code

/Keith

/***********************************************************************
 *                                                                     *
 *  AIL_BUILD_EVENT_FILTER( dsc, list, len )                           *
 *                                                                     *
 ***********************************************************************
 *
 *    This module will ILV decode an Event List, and build the corresponding
 *    Event Filter.
 *
 *  FORMAT
 *
 *    AIL_BUILD_EVENT_FILTER( dsc, event_list, len )
 *
 *  RETURNS
 *
 *    MCC_S_NORMAL      Datatype was found in the list
 *    MCC_S_INVARG      Invalid Descriptor OR Event List
 *    MCC_S_INSUF_BUF   Insufficient Event List length
 *
 *  ARGUMENTS
 *
 *    dsc      MCC_T_Descriptor   Address of an MCC Descriptor
 *    list     MCC_T_UNSLONG      Address of an array of longword
 *    len      MCC_T_UNSLONG      number of elements in the list
 *
 *  DESCRIPTION
 *
 *    This module will ILV decode an Event List, and build the corresponding
 *    Event Filter.  The Event Filter is a zero terminated array of
 *    Event Codes.  The length of the array is specified in the call.  For
 *    example, and event_list of 10 elements, would hold 9 event codes, plus
 *    the zero terminator.
 *
 * TBD script for testing Alarms Get-Event Directive
 *
 *    deposit verb 65
 *    deposit attr 10
 *    deposit inentity/class:7/instance="0"/type=24/id=13
 *    deposit inentity/class:1/link/id=0
 *    deposit inentity/class:5/wild=INSTANCE_FULL/link
 *    !
 *    deposit outentity/class:7/instance="0"/type=24
 *    deposit inp
 *    [ 0 ] (
 *        [ 1 ] (
 *            [ 1 ]  10
 *            [ 1 ]  20
 *        )
 *    )
 *
 ************************************************************************/

extern long AIL_BUILD_EVENT_FILTER( dsc, list, len )
MCC_T_Descriptor            *dsc;
MCC_T_UNSLONG               *list;
MCC_T_UNSLONG                len;

{
  unsigned long int          status;
  struct MCC_R_ILV_CONTEXT   ctx;
  int                        i;
  int                        event_count;
  int                        id;
  int			     *temp;
  MCC_T_Descriptor           event_code;

  i = 1;

  event_code.mcc_w_maxstrlen = 4;
  event_code.mcc_b_dtype     = 0;
  event_code.mcc_b_class     = 1;
  event_code.mcc_w_curlen    = 4;
  event_code.mcc_b_flags     = 0;
  event_code.mcc_b_ver       = MCC_K_VER_DESCRIPTOR;
  event_code.mcc_l_id        = 1;
  event_code.mcc_l_dt        = MCC_K_DT_UNSIGNED32;
  event_code.mcc_a_link      = MCC_K_NULL_PTR;

/*
 *  Finish Initializing the event_code descriptor.
 *  This MCC descriptor contains a pointer to the "event-filter" array.
 *  Each ILV_GET decodes the event filter number, and writes it to
 *  the array element pointed to...then the pointer is incremented to the
 *  next array element, and so on...
 */

  event_code.mcc_a_pointer = (unsigned char *) list;
  event_count              = len;

/*  (1)  Open ILV buffer
 *  (2)  Get Constructor Id
 *  (3)  Open construction
 *  (4)  Loop [until BAD status, or empty Event List array]
 *         o  Get each Event Code
 *         o  Increment Pointer to Event List array
 */

  do
    switch (i++) {
      case 1:  status = mcc_ilv_get_param_begin( &ctx, dsc );
               break;

      case 2:  status = mcc_ilv_get_id( &ctx, &id );
               break;

      case 3:  status = mcc_ilv_get_cons_begin( &ctx, 0, &k_ilv_native_value );
               break;

      case 4:  do {
                 status = mcc_ilv_get_id( &ctx, &id );
                 if (GOOD(status))
                   status = mcc_ilv_get( &ctx, &event_code );
		   /* increment the pointer by 4 BYTES --  */
		   /*        go to next longword           */
		   event_code.mcc_a_pointer +=4;
               } while (GOOD(status) && --event_count);
               break;
    }
  while ((i<=4)  &&  GOOD(status));

/*
 *  Map an ILV End-of-Constructor to a normal status
 */

  status = (status == MCC_S_ILVEOC) ? MCC_S_NORMAL : status;

/*
 *  Check the Event Filter List -- if it isn't empty yet,
 *  zero-out the next element (ie, end of list).
 *  If the list *is* empty, return a status of INSUF_BUF
 */

  if (event_count)
    *(long*) event_code.mcc_a_pointer = MCC_K_NULL_PTR;
  else
    status = MCC_S_INSUF_BUF;

  return( status );
}
	/*****  end  AIL_BUILD_EVENT_FILTER  *****/

    repl 1. & .2
    
    Thanks Keith,
    
    (1) and (2) was OK,  the reason for asking how to decode the in_p
    was that when looking at it with MCC_ILV_DUMP I got something like
    
    [1] (
       [1] (  03 04
        )
      )
    
    "03 04" could be different depending on which rule I enabled (differnet
    rules for differnet events) and I didn't get to much out of it.
    
    I'll try the code in .2 on monday.
    
    Thanks again,
    
       /Nils

repl .3

   Keith,

Thanks for the code, just one question:

It seems to me that there's a small error in the part:
       case 4:  do {
                 status = mcc_ilv_get_id( &ctx, &id );
                 if (GOOD(status))
                   status = mcc_ilv_get( &ctx, &event_code );
		   /* increment the pointer by 4 BYTES --  */
		   /*        go to next longword           */
		   event_code.mcc_a_pointer +=4;
               } while (GOOD(status) && --event_count);
               break;
    }

the EVENT_CODE.MCC_A_POINTER gets incremented once to many.  As I see
it the MCC_A_POINTER should only be incremented if and only if a
MCC_ILV_GET is done. 

As it is now when I get the bad status from mcc_ilv_get_id I don't
do a mcc_ilv_get but I still do an increment on event_code.mcc_a_pointer
and when terminating the list with MCC_K_NULL_PTR event_code.mcc_a_pointer
points one step to far. Right, or am I out of line again?

By changeing the part

                 if (GOOD(status))
                   status = mcc_ilv_get( &ctx, &event_code );
		   /* increment the pointer by 4 BYTES --  */
		   /*        go to next longword           */
		   event_code.mcc_a_pointer +=4;

to
                 if (GOOD(status))  
                 {
                   status = mcc_ilv_get( &ctx, &event_code );
		   /* increment the pointer by 4 BYTES --  */
		   /*        go to next longword           */
		   event_code.mcc_a_pointer +=4;
		 }
it works.

    /Nils

Yes - you are absolutely right!!  

I'll QAR the Alarms Code - thanks.

If there were two event codes in the list, then this would have been
generating an array of 3 codes plus the NULL terminator.  The extra
event code would be processed by the Event Manager - and could cause
some interesting side effects.  I put my Event-Id-List in my Local Context
block which is created with an 'mcc_calloc' (zero filled memory).  So, there
shouldn't be any bugs in the Alarms code because of this - but the code
will be corrected.

Thanks again - hope the rest of your coding goes well.

btw - I hope to add some examples for the Get Event directive for the
      v1.2 Toolkit (Example-FM)

/keith

    RE:-1
    
    Keith,
    I've just re-read the original note.  This is the second time I've
    heard of someone receiving an event through the Alarms-FM that they
    did not ask for.   You seem to indicate that it is not possible for
    the extra event code to be anything other than 0, true?
    
    -Matt.

Matt - anything is possible - It *is* a bug, and must be fixed.  It could be
causing a problem, but I suspect not ... but we've all been known to make
mistakes once in a while  8)

I'll Check with Anil to see if they can verify the contents of the
event filter to make sure it is/isn't causing any problems.

/Keith

Matt - I'm happy to report that the bug in the Alarms code which builds
an Event Id List is not causing any (known) problems.  I checked the
data structures in the debugger and because the Event Id List array is
calloced (zero filled memory) the pointer bug causes no problems.

btw - This section of code is only used by the Alarms Get Event Directive;
this directive retrieves Alarms Events ... This has nothing to do with
the Rule Evaluator requesting Events as specified in a Rule Expression.

/Keith

The bug reported in 1107.4 has now been fixed. The code will be available
in next release! Thanks Nils for pointing out the bug to us and
thanks to Keith for following it through and filling the QAR.

As stated in .8, at present Alarms does not have the ability to 
notify on an event list. You can specify subentity level wild carding.

So Matt, the bug reported has absolutely no possibility of Alarming on
an unasked for event!

Again as stated in 1108.4, so far when a user reports Alarms
firing on a wrong event it has been attributed to the user error.
Does not mean it does can not happen... Just that we have not seen it yet
:-)



- Anil Navkal

    Hi, more questions on event-handling:
    
    When enabling a rule with expression = 'occurs ( mymm abcd testevent)'
    my getevent-routine gets called which in turn calls MCC_EVENT_GET with
    the eventfilter for just the event 'testevent'.  It goes into wait
    state and when via MCC_EVENT_PUT I deliver a testevent it wakes up with
    the requested event and a handle-state of more.  Fine, I return with
    the event-report in the out_p argument and and handle-state of more.
    
    I get recalled and retreive my context and recall the MCC_EVENT_GET
    routine with the event-filter for testevent but this time MCC_EVENT_GET
    returns immediately with the event-code = 25  (which in the alarms-fm
    srvc-if  equals to ALARMS_RULE_FIRED ??).
    
    Now, why do I get this event that I didn't ask for?
    What should I do with it?
    Is this documented somwhere (I don't manage to find anything about
    this)?
    
       Thanks
    /Nils
    
    
    

    The handle context that you pass to the Event Manager for a MORE,
    contains data and pointers to data describing the request which was
    made, and it return the next event described by that handle context.
    My guess, is that somehow you are using the Alarms handle, instead of
    your own to call back the Event Manager.  Could that be the case?
    
    -Matt.

    repl .11
    
>>> My guess, is that somehow you are using the Alarms handle, instead of
>>> your own to call back the Event Manager.  Could that be the case?
    
    nope, I'm passing the handle which is in my context (created in
    init_handle_first and retrieved in init_handle_more).
    
    I discovered that I get event #25 only when notification is disabled.
    
    Any more suggestions?
    
       /Nils

    What is the Event Partition that you are using?  (CONFIGURATION_EVENTS or
    NOTIFICATION_EVENTS?)
    
    Also, please clarify what you mean by your "own" handle.  There are at
    least 2 handles that you have to juggle correctly in order to get this
    to work correctly.  I presume you are doing the following:
    
        Handle A
    +---------------+
    |  mcc_call_xxx |
    |  handle struct|
    | --------------|          Context A
    |  context_ptr  +----->+------------------+
    +---------------+      | Your local handle|
                           | context block    |
                           |------------------|            Handle B
                           | AHS (handle ptr) +------>+--------------+
                           +------------------+       | Event Manager|
                                                      | handle struct|
                                                      |--------------|
                                                      | context_ptr  +--+
                                                      +--------------+  |
                                                                        |
                                                                        V
                                                                  Context B
                                                               +-------------+
                                                               |Event Manager|
                                                               |internal data|
                                                               +-------------+
    
    And your algorithm, is something like...
    
    On Handle State of FIRST, you
      1) Allocate Context B, 
      2) do an AHS create for Handle B and pass that down to the Event Manager,
      3) do an mcc_ahs_set_context(HandleA, ContextA).
      4) mcc_event_get( ..., HandleB, ... )
    
    On Handle State of MORE, you
      1) do an mcc_ahs_get_context(HandleA, ContextA)
      2) mcc_event_get( ..., ContextA->HandleB, ... )
    
    Am I Right?
    
    Also, you could try turning on the Event Manager trace bits to see what
    the Event Manager "thinks" you are doing.
    
    -Matt.

    repl .13
    
>>> What is the Event Partition that you are using?  (CONFIGURATION_EVENTS or
>>> NOTIFICATION_EVENTS?)
    
    I'm using CONFIGURATOIN_EVENTS partition
    
>>> Am I Right?
    
    Yes, that's the way I do it.
    
>>> Also, you could try turning on the Event Manager trace bits to see what
>>> the Event Manager "thinks" you are doing.
    
    For the time being I'm on vacation, so I can't do the tracing right now
    (unless the weather goes really bad and I start working again...)
    
    
       /Nils