[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

1107.0. "questions on event-handling" by STKHLM::BERGGREN (Nils Berggren EIS/Project dpmt, Sweden DTN 876-8287) Thu Jun 06 1991 20:17

    Hi,

    I don't manage to understand this from the manuals, can anyone help?
    
    The description for MCC_EVENT_GET in the SRM says for the 
    event_filter-parameter that I can pass either the list of event-codes 
    I'm interested in or MCC_K_NULL_PTR for any event.  
    If I want to pass a list, I can decode the in_p argument to get 
    which event I was called for.  
    
    1.  Is this right interpreted?
    
    2.  How do I decode it.  Where is it described?
    
    3.  Does the alarms-FM do any matching between the event waited
    for and the event delivered?  Maybe a stupid question, but I manage to
    fire off a rule for one event when delivering another event... 
    (My MSL defines two events and I have two alarmrules, one for each
    event) Is it maybe that my getevent-routine has the total
    responsibility of doing this matching? (which then in turn leeds me
    back to 2.) 


   Any help is appreciated,  thanks
   
   Nils
T.RTitleUserPersonal
Name
DateLines
1107.1Event Manager FilteringNANOVX::ROBERTSKeith Roberts - DECmcc Toolkit TeamFri Jun 07 1991 14:3717
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
1107.2AIL_BUILD_EVENT_FILTER.CNANOVX::ROBERTSKeith Roberts - DECmcc Toolkit TeamFri Jun 07 1991 14:38140
/***********************************************************************
 *                                                                     *
 *  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  *****/
1107.3Thanks!, I'll try itSTKHLM::BERGGRENNils Berggren EIS/Project dpmt, Sweden DTN 876-8287Fri Jun 07 1991 19:1020
    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
1107.4code-error in .2 ???STKHLM::BERGGRENNils Berggren EIS/Project dpmt, Sweden DTN 876-8287Mon Jun 10 1991 09:1247
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

1107.5What big eyes you have grandma !! 8)NANOVX::ROBERTSKeith Roberts - DECmcc Toolkit TeamMon Jun 10 1991 10:3218
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
1107.6Looks like we've gone full circleTOOK::GUERTINI do this for a living -- reallyMon Jun 10 1991 11:339
    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.
1107.7event filter is 'calloc'edNANOVX::ROBERTSKeith Roberts - DECmcc Toolkit TeamMon Jun 10 1991 17:098
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
1107.8Event Filter bug not causing any Alarms ProblemsNANOVX::ROBERTSKeith Roberts - DECmcc Toolkit TeamTue Jun 11 1991 10:4010
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
1107.9This is to confirm that...WAKEME::ANILTue Jun 11 1991 17:4118
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
1107.10more questions...STKHLM::BERGGRENNils Berggren EIS/Project dpmt, Sweden DTN 876-8287Fri Jun 14 1991 08:1024
    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
    
    
    
1107.11RE:.10 -- Yup, that's weird all right!TOOK::GUERTINI do this for a living -- reallyFri Jun 14 1991 12:407
    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.
1107.12my own handleSTKHLM::BERGGRENNils Berggren EIS/Project dpmt, Sweden DTN 876-8287Fri Jun 14 1991 13:4413
    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
1107.13There are lots of handles flying aroundTOOK::GUERTINI do this for a living -- reallyFri Jun 14 1991 18:0148
    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.
1107.14CONFIGURATION_EVENTS, YES, LATER...STKHLM::BERGGRENNils Berggren EIS/Project dpmt, Sweden DTN 876-8287Mon Jun 17 1991 11:3919
    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