[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

3907.0. "NODE4 GETEVENT does not display everything from FCL" by CUJO::HILL (Dan Hill-Net.Mgt.-Customer Resident) Fri Oct 16 1992 00:39

I have set up a 2 routers and an 4 end nodes to sink DECnet events 
my DECmcc V1.2.0 / VMS V5.5-2 Management Station (MCCNOD).

This is the procedure I am using to set things up:
  ----    ----    ----    ----    ----    ----    ----    ----

$ manage/enterprise
DISABLE node4 MCCNOD local sink MONITOR
DELETE node4 MCCNOD local sink MONITOR
CREATE node4 MCCNOD local sink MONITOR
SET node4 MCCNOD local sink MONITOR name = MCC_DNA4_EVL
!  (MCCNOD is not a router)
DELETE node4 MCCNOD outbound stream MCCNOD remote sink MONITOR
DELETE node4 AROUT1 outbound stream MCCNOD remote sink MONITOR
DELETE node4 AROUT2 outbound stream MCCNOD remote sink MONITOR
DELETE node4 A3END1 outbound stream MCCNOD remote sink MONITOR
DELETE node4 A3END2 outbound stream MCCNOD remote sink MONITOR
DELETE node4 A3END3 outbound stream MCCNOD remote sink MONITOR
DELETE node4 A3END4 outbound stream MCCNOD remote sink MONITOR
!
CREATE node4 MCCNOD outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
CREATE node4 AROUT1 outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
CREATE node4 AROUT2 outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
CREATE node4 A3END1 outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
CREATE node4 A3END2 outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
CREATE node4 A3END3 outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
CREATE node4 A3END4 outbound stream MCCNOD remote sink MONITOR class = 0,-
	event type = {9}
!
ENABLE node4 0 local sink monitor
exit
$EXIT
  ----    ----    ----    ----    ----    ----    ----    ----

	I have another window active, besides my MCC> window,
	from which I issue NCP> TELL <node> ZERO EXEC COUNT.
	Everything works just fine for MCCNOD, AROUT1, A3END1,
	A3END2, and A3END3 as shown below:

  ----    ----    ----    ----    ----    ----    ----    ----
MCC> GETEVENT NODE4 * REMOTE NODE * ANY EVENT, FOR DURATION 00:10:00

Node4 3.1 Remote Node 3.1                   (NOTE: AROUT1 = 3.1)
AT 12-OCT-1992 10:46:45 Any Event

Successfully received events:
Event: Counters Zeroed
 Remote Node counters
	      Seconds Since Last Zeroed = 2148 Seconds
		    User Bytes Received = 0 Bytes
			User Bytes Sent = 0 Bytes
		Total Messages Received = 0 Messages
		    Total Messages Sent = 0 Messages
		      Connects Received = 0 Connects
			  Connects Sent = 0 Connects
		      Response Timeouts = 0 Timeouts
       Received Connect Resource Errors = 0
MCC>
	(same type of display for the rest)

  ----    ----    ----    ----    ----    ----    ----    ----
	Now, if I try to zero counters on the other area  
	router (AROUT2) and the other end node (A3END4), 
	I get a "success" message, but
	I don't get all of the counter info as listed above.
  ----    ----    ----    ----    ----    ----    ----    ----

MCC> GETEVENT NODE4 * REMOTE NODE * ANY EVENT, FOR DURATION 00:10:00

Node4 3.4 Remote Node 3.4		(NOTE: A3END4 = 3.4)
AT 12-OCT-1992 10:47:37 Any Event

Successfully received events:
Event: Counters Zeroed
 Remote Node counters

MCC>

  ----    ----    ----    ----    ----    ----    ----    ----

***??	Why is this?
T.RTitleUserPersonal
Name
DateLines
3907.1post some ILV output?MCC1::DITMARSPeteFri Oct 16 1992 15:1412
hiya,

try defining this logical and re-run the getevent/zero part
of your test.  then post the output.

$ define mcc_fcl_pm_log 8


p.s.

It's possible there's some good reason why phase4 can't do
what you want, but I wouldn't know it.
3907.2correct behaviorTOOK::S_KOHoot mon!Tue Oct 20 1992 19:1553
    There's nothing wrong with your setup.
    
    In the general case of remote nodes, no counter information is
    maintained unless a link has been established with the remote node so
    there is information to keep track of (eg - user bytes sent, user bytes
    received, etc)
    
    In the case where the remote node is actually the executor, a set of
    counters are maintained specific to being the executor node (some
    maintained only on full routing nodes) in addition to the counters that
    are kept for error and performance statistics as mentioned above.  See
    the NCP manual for more information about counters.
    
    Since A3END4 is an end node, and no connection has been made to itself,
    there are no counters to report when the node's counters are zeroed.
    
    To confirm this is what's happening in your case, ask for A3END4's 
    counters from MCCNOD:
    
    	mcc> show node4 a3end4 all count
    
    (Be sure not to do this on a3end4 because the DNA4_AM makes 
    a decnet link to node it is running on)
    
    you should see a response similar to the following example:
    
mcc> show node4 zayin all count


Node4 63.1019 
AT 20-OCT-1992 17:53:11 Counters

Examination of Attributes shows:
           Maximum Logical Links Active = 2 Links
                       Aged Packet Loss = 0 Packets
           Node Unreachable Packet Loss = 0 Packets
          Node Out-of-Range Packet Loss = 0 Packets
                  Oversized Packet Loss = 0 Packets
                    Packet Format Error = 0
            Partial Routing Update Loss = 0
                    Verification Reject = 0
    
    
    since node4 zayin is an end node, the counters displayed (except for
    max log links active) do not have much meaning.  hence, when the
    counters are zeroed they are not reported.
    
    you can use opcom to verify the behavior:
    
    	$ reply/enable
    	$ man/ent zero node4 a3end4
    
    hope this helps.
3907.3p.s.TOOK::S_KOHoot mon!Tue Oct 20 1992 19:162
    ignore the part about using opcom to verify - it doesn't tell you
    anything to confirm.