[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

6119.0. "Enabling rules breaks event stream?" by PRMS00::MATTHEWS () Thu Sep 15 1994 11:48

    Looking for some guidance on what appears to be anomalous behaviour by
    the event manager.  Maybe I just don't understand how its supposed to
    work.

    Background:

    - We have developed a network management system for a customer, which
    includes 9 custom global classes, each with their own set of custom
    events, children, etc.

    - VMS 5.5-2, DECnet/OSI 5.6B, DECmcc 1.3

    - We have a custom application that is designed to "get" all events
    that occur and write them to a printer.  It does this with a
    class wildcard on the mcc_event_get call.  Since the custom entities
    can go six levels deep, we have 12 threads in this process doing
    event_get - 2 at each entity spec. level (one for config. events, one
    for notification).

    - Events on the custom objects are generated by applications around the
    network and sent to a DECmessageQ - which is read by a custom event
    sink process that does event_puts.

    - Among the custom events, we have defined a critical event type and a
    major event type.  This is so we can have rules fire on events that
    applications have determined are major or critical - and have an
    alarm-fired procedure forward these events to another facility.

    Problem:

    The event printer process works great, gets every event - until I start
    enabling the rules mentioned above.  Once I enable one or more of the
    rules, events for certain classes start getting duplicated, while
    events for others aren't sent to the event printer process at all. 
    Using 3 of our custom entities - NOC, NCC, and FES - here is what I can
    consistently reproduce:

    1. If I only enable a rule for FES * critical event type, every event
    on the FES global entity, regardless of event type, is received twice
    by the event printer process (event if the rule doesn't fire).  This
    scenario does not seem to cause any lost events, however.

    2. If I only enable a rule for NOC * critical event type, all NOC
    events are duplicated, as in #1.  In addition, no FES events are
    received by the event printer process, although they do show up at a
    command line getevent in a separate session.

    3. If I only enable a rule for NCC * critical event type, I get the
    duplicates on NCC and no events come to the event printer for FES or
    NOC.

    4. If I enable all 3 rules, I get the behaviour described in 3.

    When I involve all 9 object classes in testing, it is clear that there
    is some sort of convoluted hierarchy influencing which object's events
    get dropped because of which object's rules are defined.  But whatever
    it is, it seems to be consistent.  Events on some child objects come
    through while others don't.  Strangely enough, it doesn't seem to have
    a bearing on whether events on the parent come through.  For example,
    although the NCC object events always seem to show up, events on a
    particular child of the NCC two levels down do not, but the tree below
    that chlid seems ok.

    Command line getevents always seem to work, regardless of what rules
    are defined - although the duplicate events show up there too.
    I have tried some FCL notify requests, and they seem to drop some
    events too, although I haven't determined whether the behaviour is
    exactly like that in my custom application.

    I tried a scaled-down version of the event printer process, which
    specified the NOC class in the event_get, rather than a wildcard class,
    but it behaved the same, i.e. no NOC events when I enabled the NCC
    rule.

    After disabling rules, everything starts coming through again normally.

    No COTS objects seem to be affected.  We have several collectors that
    our applications generate events on and we use similar rules on,
    and the event printer always seems to get those under all scenarios.


    Is this expected behaviour, and we are misusing the capabilities
    provided by the product?

    Does this sound like something we've done wrong in the code we have
    written?

    Could this be a bug in the product?

    Any suggestions on how to continue the attack on this problem will be
    greatly appreciated.

    Steve M.
T.RTitleUserPersonal
Name		DateLines
6119.1More info on .0 - put tracePRMS00::MATTHEWSSteve Matthews - DTN 339-5216 - COP 2-4Wed Sep 21 1994 12:34270
    
    I wrote a routine that does an mcc_event_put on the FES custom object
    referred to in .0 and I used it to trace the puts under different
    conditions, i.e. rules enabled, disabled, etc., with the event printer
    process running.  Summary of results:
    
    1. No rules enabled - I put the FES event and the event printer process
    gets it - trace says 
    PID 933, THRid 10000 Event_Put RMB selected for put: 2B4A70
    
    2. Rule enabled on the NOC class - I put the FES event, event printer
    does not get it - trace has no "rmb selected for put" line
    
    3. Disable the NOC rule - things back to normal (as in 1.)
    
    4. Start an FCL notify request on the NOC class - I put the FES event,
    event printer doesn't get it - no "rmb selected" in trace
    
    5. Terminate the notify request and try again - works (as in 1.)
    
    The put trace output with my comments follows. :
    
****No rules enabled, no notify requests outstanding
PID 933, THRid 10000 Tracing error paths in Event Manager
PID 933, THRid 10000 Tracing Event code path in Dump
PID 933, THRid 10000 Tracing Event code path in GET
PID 933, THRid 10000 Tracing Event code path in PUT
PID 933, THRid 10000 Tracing Event code path in RCB
PID 933, THRid 10000 Event_Put starting
PID 933, THRid 10000 Event_Put Input Arguments ...
PID 933, THRid 10000   p_ent_spec = 
        entity [0] wild = NOT_WILD class = 17000 id = 1 type = 5
        instance = ..+5��.�...�......wec..linthicum..fes..0..
        %X08002B35A6B401D28A8C89CA97001A00010377656301096C696E74686963756D01036665730101300000
PID 933, THRid 10000   Partition = 15
PID 933, THRid 10000   Event Code = 3
PID 933, THRid 10000   Event Data = 

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 880
    mcc_b_class     = DSC_K_CLASS_D
    mcc_w_curlen    = 33
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �......�...�.....test..testing...
    %XA182001D850104A1820016A3820012810474657374820774657374696E67850105
    mcc_a_link      = MCC_K_NULL_PTR
PID 933, THRid 10000   Time Stamp = 

Dump of MCC time descriptor:
mcc_w_maxstrlen = 16
mcc_b_dtype     = DSC_K_DTYPE_T
mcc_b_class     = DSC_K_CLASS_D
mcc_w_curlen    = 16
mcc_b_flags     = 0
mcc_b_ver       = 1
mcc_l_id        = 0
mcc_a_link      = 0
mcc_l_dt        = MCC_K_DT_BIN_ABS_TIM
mcc_a_pointer   = 
    bin_utc      = 21-SEP-1994 11:02:21.85
    time          = 01CDD55506512564
    inacc         = FFFFFFFFFFFFFFFF
    tdf_minutes   = -240
PID 933, THRid 10000 Event_Put RMB selected for put: 2B4A70
PID 933, THRid 10000 Event_Put Subscriber finished matching requests
****Event was received at event printer process
**************************************************
    
    
****enable a rule (occurs (noc * general critical event))
PID 933, THRid 10000 Tracing error paths in Event Manager
PID 933, THRid 10000 Tracing Event code path in Dump
PID 933, THRid 10000 Tracing Event code path in GET
PID 933, THRid 10000 Tracing Event code path in PUT
PID 933, THRid 10000 Tracing Event code path in RCB
PID 933, THRid 10000 Event_Put starting
PID 933, THRid 10000 Event_Put Input Arguments ...
PID 933, THRid 10000   p_ent_spec = 
        entity [0] wild = NOT_WILD class = 17000 id = 1 type = 5
        instance = ..+5��.�...�......wec..linthicum..fes..0..
        %X08002B35A6B401D28A8C89CA97001A00010377656301096C696E74686963756D01036665730101300000
PID 933, THRid 10000   Partition = 15
PID 933, THRid 10000   Event Code = 3
PID 933, THRid 10000   Event Data = 

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 880
    mcc_b_class     = DSC_K_CLASS_D
    mcc_w_curlen    = 33
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �......�...�.....test..testing...
    %XA182001D850104A1820016A3820012810474657374820774657374696E67850105
    mcc_a_link      = MCC_K_NULL_PTR
PID 933, THRid 10000   Time Stamp = 

Dump of MCC time descriptor:
mcc_w_maxstrlen = 16
mcc_b_dtype     = DSC_K_DTYPE_T
mcc_b_class     = DSC_K_CLASS_D
mcc_w_curlen    = 16
mcc_b_flags     = 0
mcc_b_ver       = 1
mcc_l_id        = 0
mcc_a_link      = 0
mcc_l_dt        = MCC_K_DT_BIN_ABS_TIM
mcc_a_pointer   = 
    bin_utc      = 21-SEP-1994 11:04:48.06
    time          = 01CDD5555D770584
    inacc         = FFFFFFFFFFFFFFFF
    tdf_minutes   = -240
PID 933, THRid 10000 Event_Put Subscriber finished matching requests
****No event was received at event printer process
**************************************************
    
    
    
****disable the rule
PID 933, THRid 10000 Tracing error paths in Event Manager
PID 933, THRid 10000 Tracing Event code path in Dump
PID 933, THRid 10000 Tracing Event code path in GET
PID 933, THRid 10000 Tracing Event code path in PUT
PID 933, THRid 10000 Tracing Event code path in RCB
PID 933, THRid 10000 Event_Put starting
PID 933, THRid 10000 Event_Put Input Arguments ...
PID 933, THRid 10000   p_ent_spec = 
        entity [0] wild = NOT_WILD class = 17000 id = 1 type = 5
        instance = ..+5��.�...�......wec..linthicum..fes..0..
        %X08002B35A6B401D28A8C89CA97001A00010377656301096C696E74686963756D01036665730101300000
PID 933, THRid 10000   Partition = 15
PID 933, THRid 10000   Event Code = 3
PID 933, THRid 10000   Event Data = 

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 880
    mcc_b_class     = DSC_K_CLASS_D
    mcc_w_curlen    = 33
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �......�...�.....test..testing...
    %XA182001D850104A1820016A3820012810474657374820774657374696E67850105
    mcc_a_link      = MCC_K_NULL_PTR
PID 933, THRid 10000   Time Stamp = 

Dump of MCC time descriptor:
mcc_w_maxstrlen = 16
mcc_b_dtype     = DSC_K_DTYPE_T
mcc_b_class     = DSC_K_CLASS_D
mcc_w_curlen    = 16
mcc_b_flags     = 0
mcc_b_ver       = 1
mcc_l_id        = 0
mcc_a_link      = 0
mcc_l_dt        = MCC_K_DT_BIN_ABS_TIM
mcc_a_pointer   = 
    bin_utc      = 21-SEP-1994 11:05:42.29
    time          = 01CDD5557DC9DCE4
    inacc         = FFFFFFFFFFFFFFFF
    tdf_minutes   = -240
PID 933, THRid 10000 Event_Put RMB selected for put: 2B4A70
PID 933, THRid 10000 Event_Put Subscriber finished matching requests
****Event was received at event printer process
**************************************************
    
    
    
****Enter an FCL notify request - any events,entity = (noc *)
PID 933, THRid 10000 Tracing error paths in Event Manager
PID 933, THRid 10000 Tracing Event code path in Dump
PID 933, THRid 10000 Tracing Event code path in GET
PID 933, THRid 10000 Tracing Event code path in PUT
PID 933, THRid 10000 Tracing Event code path in RCB
PID 933, THRid 10000 Event_Put starting
PID 933, THRid 10000 Event_Put Input Arguments ...
PID 933, THRid 10000   p_ent_spec = 
        entity [0] wild = NOT_WILD class = 17000 id = 1 type = 5
        instance = ..+5��.�...�......wec..linthicum..fes..0..
        %X08002B35A6B401D28A8C89CA97001A00010377656301096C696E74686963756D01036665730101300000
PID 933, THRid 10000   Partition = 15
PID 933, THRid 10000   Event Code = 3
PID 933, THRid 10000   Event Data = 

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 880
    mcc_b_class     = DSC_K_CLASS_D
    mcc_w_curlen    = 33
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �......�...�.....test..testing...
    %XA182001D850104A1820016A3820012810474657374820774657374696E67850105
    mcc_a_link      = MCC_K_NULL_PTR
PID 933, THRid 10000   Time Stamp = 

Dump of MCC time descriptor:
mcc_w_maxstrlen = 16
mcc_b_dtype     = DSC_K_DTYPE_T
mcc_b_class     = DSC_K_CLASS_D
mcc_w_curlen    = 16
mcc_b_flags     = 0
mcc_b_ver       = 1
mcc_l_id        = 0
mcc_a_link      = 0
mcc_l_dt        = MCC_K_DT_BIN_ABS_TIM
mcc_a_pointer   = 
    bin_utc      = 21-SEP-1994 11:07:54.41
    time          = 01CDD555CC8AC44C
    inacc         = FFFFFFFFFFFFFFFF
    tdf_minutes   = -240
PID 933, THRid 10000 Event_Put Subscriber finished matching requests
****No event was received at event printer process
**************************************************
    
    
    
****Terminate notify request on noc *
PID 933, THRid 10000 Tracing error paths in Event Manager
PID 933, THRid 10000 Tracing Event code path in Dump
PID 933, THRid 10000 Tracing Event code path in GET
PID 933, THRid 10000 Tracing Event code path in PUT
PID 933, THRid 10000 Tracing Event code path in RCB
PID 933, THRid 10000 Event_Put starting
PID 933, THRid 10000 Event_Put Input Arguments ...
PID 933, THRid 10000   p_ent_spec = 
        entity [0] wild = NOT_WILD class = 17000 id = 1 type = 5
        instance = ..+5��.�...�......wec..linthicum..fes..0..
        %X08002B35A6B401D28A8C89CA97001A00010377656301096C696E74686963756D01036665730101300000
PID 933, THRid 10000   Partition = 15
PID 933, THRid 10000   Event Code = 3
PID 933, THRid 10000   Event Data = 

Dump of MCC Descriptor reveals:
    mcc_w_maxstrlen = 880
    mcc_b_class     = DSC_K_CLASS_D
    mcc_w_curlen    = 33
    mcc_b_flags     = 0
    mcc_b_ver       = 1
    mcc_l_id        = 1
    mcc_l_dt        = MCC_K_DT_ILV
    mcc_a_pointer   = �......�...�.....test..testing...
    %XA182001D850104A1820016A3820012810474657374820774657374696E67850105
    mcc_a_link      = MCC_K_NULL_PTR
PID 933, THRid 10000   Time Stamp = 

Dump of MCC time descriptor:
mcc_w_maxstrlen = 16
mcc_b_dtype     = DSC_K_DTYPE_T
mcc_b_class     = DSC_K_CLASS_D
mcc_w_curlen    = 16
mcc_b_flags     = 0
mcc_b_ver       = 1
mcc_l_id        = 0
mcc_a_link      = 0
mcc_l_dt        = MCC_K_DT_BIN_ABS_TIM
mcc_a_pointer   = 
    bin_utc      = 21-SEP-1994 11:09:01.96
    time          = 01CDD555F4CE142C
    inacc         = FFFFFFFFFFFFFFFF
    tdf_minutes   = -240
PID 933, THRid 10000 Event_Put RMB selected for put: 2B4A70
PID 933, THRid 10000 Event_Put Subscriber finished matching requests
****Event was received at event printer process
6119.2Problem occurs on Notification Window as wellPRMS00::MATTHEWSSteve Matthews - DTN 339-5480Fri Sep 30 1994 12:353
    In case it sheds any light on the problem, I have the same events
    missing and duplicated in the Notification Window, under exactly the
    same conditions as described in .1
6119.3Correction to -.1 - Notif. window is not the samePRMS00::MATTHEWSSteve Matthews - DTN 339-5480Tue Oct 04 1994 11:584
    Please disregard .2
    The Notification window does not behave the same way as the custom
    software.  It seems to behave inconsistently, but as soon as I can get
    some systematic testing done with it I'll post the results.