Conference azur::mcc

    Raj,
    
    After installing MCC T1.3.0, I advise you to check SYSGEN/QUOTA
    parameters with mcc_common:mcc_audit.com procedure ; I've met the same
    problem as you've met before running it because of that...(effectively,
    the detached IP poller process was created but died immediatly without
    any message in sys$error. and sys$output.).
    
    Renato

    The quotas are ok and the poller process does not die.  It is active
    all the time but the notification does not come in.
    
    Raj

    
    Raj,
    
    When you create the request...
    
    mcc>notify domain <domain> entity list=(snmp *), -
    		event=(IP reachability UP,IP reachability DOWN)
    
    ...please also keep in mind that the request does only take in account the
    existing SNMP members of the given domain... That means that after
    enabling this request, if you add a new SNMP member in the given
    domain, you have to disable/enable the request to include your new SNMP
    member in the population processed by the request...
    
    I know it is surprising, but there is currently a problem with
    NOTIFIICATION FM dynamic mechanism (the problem also exists for any
    class).
    
    The problem is currently officially reported by me (local ECSO related
    to QAR #00335), for DECmcc/BMS V1.2. But the problem still exists in
    DECmcc T1.3.0.
    
    Maybe you have to check this kind of situation before testing again Ip
    Poller...
    
    Renato
    
       

    Renato,
    
    Thanks,  the problem was due to registeration with V1.2.  I
    deregistered and registered and it works.
    
    Raj

    glad to hear you got it working Raj.  Just a quick note on the
    notification handling of dynamic changes to a domain. Unluckily
    this problem is true for all FMs that support wildcards.  The domain
    FM currently does not inform anyone when a change has been made
    to the domain membership.  What we are hoping for is a change to
    the domain FM such that it provides an event informing all interested
    parties anytime a domain change is made (addition or deletion).
    
    jill
    

    
    
    To .5,
    
    Jill,
    
    You're probably right about internal mechanisms to provide an
    ansynchronous and dynamic inclusion/exclusion operation of member(s) in
    a given domain.
    
    But, wouldn't it be possible to automatized via Notification
    Application Services, the proposed workaround which consists of copying
    the current enabled requests for a GIVEN domain (the domain where the
    modifications have just been made during an interactive session...),
    enabling the new request and deleting the previous one... It would be
    an external mechanism to take in account inclusion/exclusion of
    member(s) in a GIVEN domain.
    
    Any opinion about that approach ?
    
    Renato
    

    
    Hi Renato,
    
    Okay, if I understand you correctly it might be possible to have
    the PM take such an action.  I believe what you are proposing is
    that everytime the user modifies the membership of a domain from
    within the Iconic Map interface, the PM should automatically disable
    and then reenable all notification requests on that domain. 
    
    Adding this kind of function is most likely possible, but it does
    not solve the following problems:
    
    	1)  if changes are made through another interface (FCL or another
    	    user) they will not be seen by this instance of the PM
    	2)  when should the disable/enable of the notify occur, should
    	    there be a timer and only if no additional changes are made
    	    to the map within this period should the update occur;
    	    keep in mind that starting a notify command is cpu intensive
    	    and does require request to be sent out over the net
    	3)  should the notify command be updated everytime the map is
            locked after an "edit" session
    
    Overall I think that most MCC systems are being utilized as single
    user systems, so that what you are asking for is not unreasonable.
    I will pass this along, but my personal preference is to extend
    the domain FM so that it informs other MMs when changees to the
    domain are made. This feature would allow all FMs, not just
    notification, to be more extensible (though your approach would
    most likely be quicker to implement for just notification).
    
    jill
    

    
    Hi Jill,
    
    >Overall I think that most MCC systems are being utilized as single
    >user systems, so that what you are asking for is not unreasonable.
    >I will pass this along, but my personal preference is to extend
    >the domain FM so that it informs other MMs when changees to the
    >domain are made. This feature would allow all FMs, not just
    >notification, to be more extensible (though your approach would
    >most likely be quicker to implement for just notification).
    
    You're totally right about the limit of my suggestions. That's why I
    think it would be a good think to implement communication mechanim
    between MMs more generally, the more efficient as possible (in CPU
    time...). Do you think we can hope to see such a mechanism implemented
    in V1.3 ? Or later ?
    
    Regards,
    Renato
          

    definitely NOT in v1.3, as Eric mentioned in an earlier note we
    are real close to final code freeze and field test update. As to
    in a future release well I have passed your request along as good
    input into V.next requirements.  Ask again in a month or so and
    see if it made the list.