Conference azur::mcc

3115.0. "NOTIFICATION use GETEVENT on fullINSTANCE wildcarded global entity?" by KETJE::PACCO () Tue Jun 02 1992 07:52

	What is the logic behind the following behaviour ?

When the following command is issued:

MCC> Notify domain MY_DOMAIN Entity list (XXX YYY), Event (Any events)

The Notification FM is calling the XXX access module executing a:

1). SHOW XXX YYY all identifiers.
2). GETEVENT XXX * Any events 


My problem is in the second part with the GETEVENT. Why is the access module 
called in this case with a INSTANCE_FULL wildcard instead of (what I expected)
a specific entity instance as in the SHOW all identifiers?

Does this mean that a GETEVENT entry point always has to support FULL_INSTANCE
wildcarding for the global entity?  Must the AM execute a DIRECTORY XXX * 
command to find out which instances are known in the network?  This sounds 
crazy.  Can this be clarified?

Regards,
Dominique.


The following lines shows a trace of this situation.

$ manage/enter/deb

DECmcc (T1.2.7)

MCC> notify domain dectown ent list (online chipcom_hub), event (any event)
%MCC-S-NOTIFSTART, Notify request 1 started
MCC>
%DEBUG-I-DYNIMGSET, setting image MCC_ONLINE_AM
DEBUG-I-DYNMODSET, setting module MCC_ONLINE_AM_INIT
DBG> g
Routine <MCC___ONLINE_AM_ACTIONS>
%DEBUG-I-DYNMODSET, setting module MCC_ONLINE_AM_SRVC
DBG> g
Service interface dump
Directive SHOW
Partition IDENTIFIER
Handle in input AHS dump
Handle state FIRST
Input entity AES dump
        entity [0] wild = NOT_WILD class = 9999 id = 101 type = 5
        instance = �....��3��.......chipcom_hub..
        %XAA0004000FC0C033B6E6B90393000F00010B63686970636F6D5F6875620000
Return from VALDT_CALL_ARGS: 52854793
        entity [0] wild = NOT_WILD class = 9999 id = 101 type = 5
        instance = �....��3��.......chipcom_hub..
        %XAA0004000FC0C033B6E6B90393000F00010B63686970636F6D5F6875620000
Return from CREATE_CONTEXT: 52854793
Return from SET_CONTEXT: 52854793
Return from CREATE_S_ENTITY: 52854793
Return from CALL SNMP ONLINE: 52854793
Return from AHS_REINIT: 52854793
Return from DELETE_CONTEXT: 52854793
Service interface dump
Handle in output AHS dump
Handle state FIRST
Output entity AES dump
        entity [0] wild = NOT_WILD class = 9999 id = 102 type = 73
        instance = .�.K
        %X10B7004B
Output parameter ILV dump

[  1 ] (
    [  1 ] (
        [  102 ] (
            [  1 ]             49  -- I
            [  2 ]             10 b7 00 4b
            [  3 ]             00
            )
        [  103 ] (
            [  1 ]             47  -- G
            [  2 ]             08 00 8f 10 22 fa
            [  3 ]             00
            )
        [  101 ] (
            [  1 ]             05
            [  2 ]             aa 00 04 00 0f c0 c0 33 b6 e6 b9 03 93 00 0f 00
            69 70 63 6f 6d 5f 68 75 62 00 00
            [  3 ]             00
            )
        )
    )


Routine <MCC___ONLINE_AM_GETEVENT>
DBG> g
Service interface dump
Directive GETEVENT
Partition CONFIGURATION_EVENTS
Handle in input AHS dump
Handle state FIRST
Input entity AES dump
        entity [0] wild = INSTANCE_FULL class = 9999
Return from VALDT_CALL_ARGS: 52854873
Service interface dump
Handle in output AHS dump
Handle state FIRST
Output entity AES dump
        entity [0] wild = INSTANCE_FULL class = 9999
Output parameter ILV dump
     [  12 ] (
    [  2 ]     03 26 80 09
    )
%MCC-E-NOTIFEXCP, notify request 1 encountered an exception
Unexpected condition returned to Notification FM.

MCC>  Exit
%DEBUG-I-EXITSTATUS, is '%MCC-S-NORMAL, normal successful completion'
DBG>  Exit
    

  Dominique,

  I don't know what the Notification FM is doing .. or why .. but your
  Management Module GETEVENT directive should support a Global Wildcard.

  The good news ... your directive need only validate (ie, accept) a global
  wildcard for GETEVENT and pass it on to the event manager; as the event
  manager can handle a global wildcard.

  If you are using the Toolkit Design Framework, check out the the Example
  FM GETEVENT directive source code for more information.

  /keith

    Keith,
    
    Thanks for this info.  I assume this requirement is one of the new
    1.2.7 field test, because I have never encountered this before.
    
    I haven't seen this requirement in the books too. I hope all these "special"
    requirements will be CLEARLY documented in the developement manuals,
    otherwise we will suffer from phone calls from all customers developing
    management modules.
    
    This change in requirement has broken two of my access modules, and
    makes the implementation of one of these now a LOT more complex now.
    
    In fact because my access module has now to support a wildcarded global
    entity for the GETEVENT directive, and because I get my events from
    a GETEVENT to the generic SNMP access module, I now will receive ALL SNMP
    events, even the ones in which I am not interested in, and the amount of
    these can be 100 times more than the ones I have to consider.
    This means first a lot of CPU cycles lost.
    
    But the MAJOR PROBLEM is now that the AM should try to find out if a
    SNMP event has to be processed or has to be discarded, just based on the
    IP address.  The SNMP event carries NO information about the type of
    entity from which it was generated.
    
    The conclusion of all this:
    This requirement implies a VERY serious increase in COMPLEXITY of
    the AM coding to work around this, therefore also several more weeks
    for developement, and a serious impact on the (already lousy) performance
    of the system.
    
    Dominique.

    I would expect that the 'requirement' that notification requires the
    service of Getevent on a global wildcard to be located in the MRM for
    the Notification FM.
    
    It is important that MM writers understand the importance of matching
    'services offered' by one module with the 'services required' by
    another in order that the two modules interoperate. We have chosen MRMs
    as the means to document the services:
    	PMs generally only require services
    	AMs generally only offer services
    	FMs usually both offer services (to PMs or to other FMs)
    		and require services (of AMs or of other AMs)
    (Of course, all MMs would normally offer services corresponding to
    their self management).
    
    Colin

  Could someone from the Notification Team help here.  What are the
  requirements (services required) of the Notification FM?

  /keith

    As a MM writer it would be nice to be "informed" about these changes,
    and not find out in the hard way that suddenly from a certain version
    on something does not work any more or breaks.  Just updating the
    NOTIFICATION MRM is not enough, because you cannot expect people  to go
    through ALL manuals to find out of something changes compared to the
    previous version.
    
    This is clearly something to write down in the release notes !
    
    Dominique.