Conference azur::mcc

1617.0. "Problem with event filtering ?" by KETJE::PACCO (To manage you have to be a (manag..) skilled person!) Tue Oct 08 1991 14:41

Can there be a problem with event filtering ?

In this example, the getevent is waiting for only 1 sinle event.
    The event_trace shows that the filter is set-up for event #2, which is
    right.

The Event sink program, injects an event with #1.
The getevent directive continues, (instead of waiting) and shows the event
    #1 ... which was not wanted.

Regards,
Dominique.
*******************************************************************************
Event report using a GETEVENT directive.
*******************************************************************************
$ manage/enter getevent uaf pacco spec att
DECmcc (V1.1.0)

%MCC-S-NORMAL, normal successful completion
Tracing error paths in Event Manager
Tracing Event code path in GET
Tracing Event code path in PUT
Event_Get starting
Event_Get processing Partition argument
Event_Get Input Arguments ...
  in_entity =
        entity [0] wild = NOT_WILD class = 33 id = 1 type = 4
        instance = ..PACCO
        %X0105504143434F
  Partition = 15
  Filter = 2
  time_spec = MCC_K_NULL_PTR
        Handle context not set up yet
Event_Get handle state = MCC_K_HANDLE_FIRST
Event_Get building a PRMB for this request
Event_Get creating a Heartbeat thread for this request
Event_Get setting the Heartbeat thread-id 1000A
Event_Get creating TimeStamps
Event_Get requesting NEXT event
Going to wait for the event now...
Event_Get was Signalled
Copying Event Data to user supplied buffers
Event_Get converting time to supplied time type
Event_Get deleting global event data
Event_Get performing general clean up
THUMP!
Failed to dequeue event:
%MCC-E-NOMOREVT, no more events in event queue
Event_Get Output Arguments ...
        Handle context not set up yet
  out_entity =
        entity [0] wild = NOT_WILD class = 33 id = 1 type = 4
        instance = ..pacco
        %X0105706163636F
  timestamp =   8-OCT-1991 17:11:00.18
  Event Code = 1
  Event Data =

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 1024
    mcc_b_dtype     = DSC_K_DTYPE_T
    mcc_w_curlen    = 12
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �...�...�...
    %XA1820008A1820004A1820000
    mcc_a_link      = MCC_K_NULL_PTR
Event_Get completed

uaf pacco
AT  8-OCT-1991 17:11:00 CONFIGURATION

UAF event received
Attention, event without argument




*******************************************************************************
Event sink program, which caused the previous event.
*******************************************************************************
$ run uaf_event

UAF Entity instance : pacco
AES Dump of entity :
        entity [0] wild = NOT_WILD class = 33 id = 1 type = 4
        instance = ..pacco
        %X0105706163636F

UAF Event code (1,2): 1
ILV Dump of event report :

[  1 ] (
    [  1 ] (
        [  1 ] (
            )
        )
    )
Tracing error paths in Event Manager
Tracing Event code path in GET
Tracing Event code path in PUT
Event_Put starting
Event_Put processing Partition argument
Event_Put Input Arguments ...
        entity [0] wild = NOT_WILD class = 33 id = 1 type = 4
        instance = ..pacco
        %X0105706163636F
  Partition = 15
  Event Code = 1
  Event Data =

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 128
    mcc_b_dtype     = DSC_K_DTYPE_T
    mcc_w_curlen    = 12
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �...�...�...
    %XA1820008A1820004A1820000
    mcc_a_link      = MCC_K_NULL_PTR
  Timestamp =   8-OCT-1991 17:11:00.18
Event_Put getting current time
Event_Put converting user supplied time into BAT
Event_Put building an EDS structure to store Event Data
Event_Put creating an AHS
Event_Put Locking Subscriber structures
Event_Put Subscriber searching for first(/next) matching request
Event_Put Subscriber Handle state = MCC_K_HANDLE_MORE
Event_Put Subscriber Locking RMBs
Event_Put Subscriber found Request for NEXT Event
Event_Put Subscriber referencing Event Data
Event_Put Subscriber building a Event Data Queue Element
Event_Put Subscriber sending an Event to a Requestor
Event_Put Subscriber Unlocking RMBs
Event_Put Subscriber searching for first(/next) matching request
Event_Put Subscriber Handle state = MCC_K_HANDLE_FIRST
Event_Put Subscriber finished matching requests
Event_Put Unlocking Subscriber structures
Event_Put cleaning up
$
    

    Since the time DECmcc was restarted, I cannot reproduce this any more.
    
    I assume something interfered or was not defined correctly during
    the tests ... but it still remains a strange feeling.
    
    Dominique.

    Yes.  I know it looks bad.  But I can assure you that when you pass
    down specific events, we match by using a "compare longword" machine
    instruction.  For this to fail, the VAX would have to say that a
    1 is exactly equal to a 2.
    
    But, there are other possibilities of course :-) ... You may have
    inadvertently thrown the Event Manager a curve ball.  This might happen
    if you "quit" out the debugger, instead of "exit".  Or perhaps you
    re-executed some code without "cancelling" the event_get handle,
    thereby somehow mapping TWO requests (an old obsolete one and the last
    correct one) to the same handle context.  In other words, if there
    is an old request for event #1 still hanging around in the event pool,
    the event manager could on rare occasions (with the help of the
    developer or end user) be tricked into sending it to a requestor
    requesting event code #2.  Just a theory I have.  I'll try to look
    into it further.  Meanwhile, please make sure that all Event_Get()
    calls are cancelled properly, and never use the "quit" command in
    the debugger (I'm sure that's in the release notes).
    
    Thanks for letting us know about this anomoly.
    
    -Matt.