Conference azur::mcc

    
    To set the LOCAL SINK MONITOR name attribute:
    
    	mcc> set node4 0 local sink monitor initial name mcc_dna4_evl
    	
    	to set it in the permanent database.
    
    	mcc> set node4 0 local sink monitor name mcc_dna4_evl
    
    	to set it in volatile.
    
    This should be done before logging is enabled.

    RE: .1   Thanks for the reply. I tried your suggestion, still no luck.
    
    What I did notice is that I can see the name from FCL but not from NCP!
    
    MCC> show node4 0 local sink monitor all attr
    
    Node4 1.12 Local Sink Monitor
    AT 13-AUG-1992 08:32:56 All Attributes
    
                                       Type = Monitor
                                      State = On
                                       Name = "MCC_DNA4_EVL"
                               Initial Type = Monitor
                               Initial Name = "mcc_dna4_evl"
                              Initial State = On
    MCC>  Exit
    NEWF> ncp sho known logg
    
    
    Known Logging Volatile Summary as of 13-AUG-1992 08:34:16
    
    
     Logging sink type = monitor
    
        Sink Node       Source               Events                   State
    Name
    
                                                                       on
        1.12 (NEWF)     (All sources)        0.0-2 4-6
                                             8-9
                        (All sources)        2.0-1
                        (All sources)        3.0-2
                        (All sources)        4.0-19
                        (All sources)        5.0-21
                        (All sources)        6.0-5
                        (All sources)        7.0-11
    NEWF>
    
    
    Any hints for what to look for? The events still aren't passed on to
    MCC...
    
    Thanks,
    
    Ed

    
    for some reason, on V5.5 system, the name characteristic is not
    displayed with the summary information in NCP as it was in V5.4.  
    Please confirm by trying:   NCP> SHOW K LOG CHAR
    
    Please check your MCC_DNA4_EVL log file - are there any errors 
    reported?  (It is in the SYS$LOGIN directory of the account you enabled
    it from).

    Thanks for your reply. Yes, NCP SHOW KNOWN LOGG CHAR does indeed show
    the name attribute.
    
    But I still have no events showing up in MCC... I have notification
    enabled on the iconic map. I do get notifications from my DATA
    COLLECTOR but have not succeeded at getting any DECnet (Phase IV)
    events triggering notification.
    
    The MCC_DNA4_EVL.LOG looks fine:
    
    $ manage/enter/presen=mcc_dna4_evl
    Declared network object MCC_DNA4_EVL,13-AUG-1992 08:28:04.29
    Wait for EVL link,13-AUG-1992 08:28:04.30
    Connected to EVL,13-AUG-1992 08:28:12.77
    
    I must be overlooking something obvious... Any ideas/hints?
    
    Thanks,
    
    Ed

    
    what does your notification request look like?
    
    are there any partially registered NODE4 entities in your domain?
    
    if you issue a GETEVENT request for a DNA4 event, do you get a
    response?

    RE: .-1
    
>>	what does your notification request look like?
    
    Request State = enabled
    Domain = my_domain
    Entity List =(Node4 *)
    Events = (Any Events)
    
>>	are there any partially registered NODE4 entities in your domain?
    
    Yes
    
    >>	if you issue a GETEVENT request for a DNA4 event, do you get
    	a response?
    
    No. It just sits & hangs there...
    
    MCC> getevent node4 0 Counters Zeroed
    
    
    Thanks for your reply,
    
    Ed
    

    Ok, this is a stab in the dark.
    
    I had the same problem not being able to get events from a V5.5 system,
    note my remote node is part of a LAVc.
    
    What I did find is that if I bounced the circuit up and down a few
    times, then wate say 10 to mins.  then issue a 
      
    	NCP>clear log mon sink node <noded_name_of_mcc> know event
    
    Then all the events came into mcc in a burst.
    
    The time to wate seemd to be variable

    RE: .6
    
    Hi Ed,
    
    The reason i asked about partially registered entities in your domain
    is because there is a bug in NOTIFICATION where if the first member of
    the domain in that class is partially registered, NOTIFICATION is
    unable to obtain identifier information.  There will be a patch for
    this.  In the mean time, a work around is to create a domain rule
    for the particular event(s) - for example:
    
    	mcc> create domain my_domain rule r1 exp=(occurs( -
    	_mcc> node4 * remote node * any event))
    
    To check for the counters zeroed event for node4 entities, the request
    must be made for REMOTE NODE's:
    
    	mcc> getevent node4 0 remote node * counters zeroed.
    
    This also applies to the executor node.
    
    I am not sure yet where the break down is in your situation - if it is
    at the DECnet side, in the AM, or in Notification.
    
    As mentioned in .7, we have also at times experienced trouble getting
    DECnet to send events on to the MCC DNA4 sink.  I don't know what
    causes the 'hold up' of the events.  Disabling/Enabling the monitor,
    and sometimes restarting EVL was found to be helpful.  To help  us
    debug we set the logical EVL$LOG in EVL.COM.
    
    -s
    

    Thanks for the replies,
    
    Here's what I've done:
    
    � I fully registered the partially registered nodes in this domain.
    � I stopped/restarted my MCC process, EVL and MCC_DNA4_EVL.
    � Saw no change in the behaviour...
    
    Next:
    
    � I created the occurs rule as in .7 occurs(node4 * remote node * any
    	event))
    � Enabled the above rule
    � Enabled notification.
    
    MCC> enable domain .domain.mohawk_oil_vancouver rule r1
    
    Domain NEWF_NS:.domain.mohawk_oil_vancouver Rule r1
    AT 14-AUG-1992 09:15:17
    
    Normal operation has begun.
    MCC> notify domain .domain.mohawk_oil_vancouver
    %MCC-S-NOTIFSTART, Notify request 1 started
    MCC> getevent node4 0 remote node * counters zeroed
    
    *********
    
    Then I zeroed the counters on the DECrouter 150 (which sinks it's
    events to my MCC node). Zip... zilch from MCC... OPCOM did report the
    0.9 event properly...
    
    So, even with the occurs rule, I still can't pick up counters zeroed...
    I created a notify request in the iconic map (Node4 * Any event) and it
    did pick up other events (Node Reachability Change) but it still
    doesn't see the counters zeroed.
    
    My MCC node is a non-routing node... Does that matter?? Also, I did a
    show process/cont on MCC_DNA4_EVL while I was zeroing the counters...
    It alternates between HIB and COM states but always stays at PC
    7FFEDF8A; the BUFIO does increase by 1 with every event (DIO static).
    
    Your help is appreciated!
    
    Thanks,
    
    Ed
    
    PS. I would really like to avoid using the alarm rule since I would
    like to see the actual event in the Notification Window (in IMPM). By
    using the rule, the window displays "Rule R1 has fired" as opposed to
    displaying the actual event...
    
    If there's a patch available, I'd be REALLY interested in trying it
    out!

    
>>    MCC> getevent node4 0 remote node * counters zeroed
    
    This request looks for remote node counters zeroed for the 
    host node (eg - if you are logged onto NEWF:: and zero counters on NEWF
    for some node, this getevent request should get a reply.)  
    
    I checked around and found out that SOME DECnet implementations
    report the local (EXEC) counters as NODE4 COUNTERS ZEROED where others
    will report it as NODE4 REMOTE NODE COUNTERS ZEROED.
    
    So, if you are going to zero exec counters on the DECrouter 150,
    then try request:
    
    	mcc> getevent node4 * counters zeroed
    	mcc> getevent node4 * remote node * counters zereod
    
    (or any config event)
    
    p.s.  you do not need to be a routing node to receive the events.
    	  i think that the events are getting from EVL to DNA4 sink.  just
    	  need to figure out how to retrieve this particular event from MCC.
    
    p.p.s.  we are in the process of producing and testing the patch.
    	    it will be announced in the notes file as soon as it becomes
    	    available.