[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

3550.0. "Can't set Logging Monitor Name to MCC_DNA4_EVL" by KAOFS::BOIVIN (Moi, j'viens du nord!) Thu Aug 13 1992 01:25

T.RTitleUserPersonal
Name
DateLines
3550.1setting name attributeRAMPAL::S_KOHoot mon!Thu Aug 13 1992 14:5812
    
    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.
3550.2I see it from FCL but not from NCP...KAOFS::BOIVINMoi, j'viens du nord!Thu Aug 13 1992 15:3845
    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
3550.3show know log char to see name attributeRAMPAL::S_KOHoot mon!Thu Aug 13 1992 19:238
    
    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).
3550.4Yes, I see the name but still no events...KAOFS::BOIVINMoi, j'viens du nord!Thu Aug 13 1992 20:0920
    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
3550.5more info pleaseRAMPAL::S_KOHoot mon!Thu Aug 13 1992 20:407
    
    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?
3550.6GETEVENT hangs...KAOFS::BOIVINMoi, j'viens du nord!Thu Aug 13 1992 22:1825
    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
    
3550.7try clearing log sink see if they come in thenHERON::PATEL_ALoLo-AQIC-I82Q-B4IP, - LMFFri Aug 14 1992 08:1413
    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
3550.8RAMPAL::S_KOHoot mon!Fri Aug 14 1992 14:3932
    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
    
3550.9Creating rule helps... a bit...KAOFS::BOIVINMoi, j'viens du nord!Fri Aug 14 1992 16:4054
3550.10RAMPAL::S_KOHoot mon!Fri Aug 14 1992 19:3626
    
>>    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.