Conference azur::mcc

    I get the same message after enabling SNMP Events
    => I did not investigate so far
    
    seems to have a common reason...
    
    					Guenter
    

    Check to see if the various listner processes are still running.
    
    For Phase V, it is MCC_DNA5_AM....I believe it is MCC_DNA5_AM for PhaseIV
    ...not sure, but probably MCC_SNMP_AM for SNMP.
    
    I've experience something similar and when it happens, the receiving 
    process appears to abort.  
    
    How many systems are sinked to your MCC station?
    
    How many notification events are you attempting to startup during
    startup?   I've found that starting them a few at a time seems to work
    better than starting them all at once.  I still say there is a bug
    somewhere either in notification or the kernel itself which is not able
    to handle startup of notification while other systems are attempting
    to communicate.
    
    I've QAR'd it.
    
    Al
    

    I just want to receive "any configuration event" on SNMP
    the only other events I use is one Router sending Phase4 events
    => minimum setup only
    
    Strange thing: today the customer called me and told me that he
    actually got
    SNMP Events from a failing FDDI Device
    => so it seems to work anyhow...
    
    					Guenter

    I was at a customer site yesterday where they get this message from the
    IMPM
    Notification request 4
    the event sink was started but is not currently communicating.
    
    
    Is there any answer to the QAR?
    why does this happen and how do we get rid of it?
    thanks,
    Mike

    The error message "the event sink was started but is not currently
    communicating" is generated by the SNMP AM when it successfully started
    the SNMP Event Sink process, but the SNMP AM wasn't able to subsequently
    communicate with the event sink via the event pool.
    
    This usually means that the event sink process came up, however, it 
    encountered a fatal error during its initialization and died. I've seen 
    this happen only on VMS using UCX. It seems UCX gets in a wierd state
    and won't let the event sink open a socket and bind it to the SNMP trap 
    port 162. I stopped UCX (@sys$startup:ucx$shutdown) and restarted UCX
    (@sys$startup:ucx$startup) and then everything worked fine.
    
    Can you bring UCX up and down to see if the problem goes away? I
    realize this is not a long-term solution but it will help us isolate 
    the problem better. Thanks.                               
    
    jim
     
     
    

    I have the same problem, so I took your advise and shut down UCX and
    restarted it.  No Luck.. Same problem.  
    
    Mike

    
     Hi,
    
     On a customer site we have the same problem as mentioned.
     The notify request is the following:
      domain:
      entity : snmp *,events = Any events ,severity = warning
    
     If I use in the notify request a more specific event, than the error
     disappears.
    
     Can this be an explanation ?
    
     Regards,
    
    
      Yves
    
      

    More info,
    
    I can reproduce the problem with the following sequence.
    
    Only 
    
    Notify Domain snmp Entity List = (snmp *), Events = (Any Events)
    
    is normally accepted without problem
    If the following sequence is added 
    
    Notify Domain snmp Entity List = (snmp * Chipcom), Events = (Any Events)
    
    or for instance,
    Notify Domain snmp Entity List = (snmp * Chipcom), Events = (ChipHello) 
    
    Then the message appears on the screen and the traps are not working.
    you can simulated it also in the reverse order 
    
    Notify Domain snmp Entity List = (snmp * Chipcom), Events = (Any
    Events) 
    
    and then
     Notify Domain snmp Entity List = (snmp *), Events =
    (Authenticationfailure)
    
    By the way occurs rules works find (that is a possible workarround),
    test general SNMP Traps via Rules while Enterprise specifics are only notified (
    or vice-versa).
    
    Regards,
    Robert 
    
    NB: Customers is expecting a fix for that  :-((
    

We have the same problem. Is there any solution or fix availible???

Or is it like with all the other MCC problems ---- no answer, --- no feedback,
--- just quiet.


Roland

Please take a look at note 7, especially the later replies.
The workload in engineering is such that we are no longer able
to provide support through this conference.  If you have a customer
problem that can't be handled in the field, please escallate through
the appropriate channels.  That way we can focus the limited engineering
resources that we have available.

-- Erik