Conference azur::mcc

    What you need to do is tell the remote node to use your local node as a
    sink node (where MCC is running). The remote node does not have to have
    MCC running - just DECnet.
    
    Use the Create or Pass command in order to set up the events to go to
    your local node. For the global entity (NODE4) use the remote node
    name. Then use your local node's name as the Outbound Stream entity id
    and Monitor as the Remote sink entity's name.
    
    For example. 
    	Create Node4 remote-node-id Outbound Stream your-local-node Remote
    							Sink Monitor
    							event...
    
    (for event format look at the documentation)
    
    What you just did, was to inform the remote node to sink events
    (whatever) to the monitor process on your local node. The monitor
    process will be (should be) the DECmcc Event Monitor.
    		Cindy
    (Hope concepts haven't changed since last spring!)

    The CREATE NODE4 REMOTE-NODE-ID .... command seems to work correctly,
    because on the local node(where DECmcc is running), OPCOM messages can
    be received from the remote node
    			e.g. NCP> ZERO EXECUTOR COUNTERS
    
    However, DECmcc seems not to handle these events coming from that
    remote node.
    
    The alarm rule
    (OCCURS(NODE4 local-node-id REMOTE NODE remote-node-id COUNTERS
    ZEROED))
    does not fire when I execute the command on the remote node
    NCP> ZERO EXECUTOR COUNTERS
    
    Is there something wrong with the alarm rule ?
    
    On the other hand, 
    (OCCURS(NODE4 local-node-id REMOTE NODE local-node-id COUNTERS ZEROED))
    does fire correctly when NCP> ZERO EXECUTOR COUNTERS is executed
    locally.
    
    Dominique.

   RE: .2

   I think Alarms rule is not firing because MCC does not see the 
   counters zeroed event from the remote node. You can very easily 
   verify this hypothesis by issuing the following command.

   MCC> getevent NODE4 local-node-id REMOTE NODE remote-node-id COUNTERS -
   _MCC> ZEROED

   Then from another process issue the ZERO EXEC COUNTERS command on
   the remote node.

   Please let us know if the GETEVENT gets the event but Alarms
   do not fire. 

    As to why MCC is not "seeing" the remote node counters zeroed
    event, I leave that to the DECNET experts!

    - Anil

    
    In getevent requests, the entity specifier reflects the place where the
    event occurs, not the place where it is received and interpreted.
    
    The Node4 specifier should be the Node4 where the event occurs, in your
    case, "remote-node-id".  So, to receive the Counters Zeroed event
    generated at the remote node, you want the rule to look like this:
    
    (OCCURS(NODE4 remote-node-id REMOTE NODE remote-node-id COUNTERS
    ZEROED))
    
    And you should make sure that the node4 "remote-node-id" is sinking
    it's counters zeroed event to Outbound Stream local-node-id Remote Sink
    Monitor for the event to be delivered to DECmcc.  It sounds like you've
    already made sure the DECmcc event monitor is set up correctly.  On the
    local node (with DECmcc) you can set all this up, or you can go to the
    remote node, and use it's NCP to set up the logging sink correctly.  It
    is all manipulating the same databases.
    
    DECnet keeps a number of counters (the remote node counters) which keep
    information about remote nodes to which you have a connection, or
    recently had a connection.  On your local node, if you have a connection to
    the remote node "remote-node-id", then there are a bunch of counters with
    information about the traffic between the two nodes.  It is these
    counters, on your local DECmccc node about remote node "remote-node-id"
    that you would zero to trigger the event as you created it:
    
    (OCCURS(NODE4 local-node-id REMOTE NODE remote-node-id COUNTERS
    ZEROED))
    
    That is, to make your original rule fire, do this at your local node:
    
    MCC> ZERO NODE4 local-node-id REMOTE NODE remote-node-id
    
    This will clear those local traffic counters, and an event report about
    zeroing those will be returned.
    
    The key is simple:
    
    In any getevent, specify the entity at which the event occurs,
    regardless of where you intend to receive the event report.  That, and
    make sure that the node4 is sending those event reports to your sink.
    
    Sorry for the confusion, hope this clears it up for you.
    
    -Jim Carey
    
    
    
    
    

    Note 734.4 did clarify a lot.  In fact the behaviour of our DECmcc
    director was and is still strange.
    
    After having directed all remote and local DECnet events to the local
    sink MCC_DNA4_EVL, have set a terminal session on the local system with
    REPLY/ENA=NETWORK so I could follow all events reported on the local
    node, coming from the local and remote node.
    
    What happened is the following:
    GETEVENT NODE4 local-node-id REMOTE NODE local-node-id COUNTERS ZEROED
    always fired, when the local counters were zeroed
    
    GETEVENT NODE4 * REMOTE NODE * COUNTERS ZEROED fired also about always as
    expected, on local and remote counters zeroed.
    
    However, several times we did
    GETEVENT NODE4 remote-node-id REMOTE NODE remote-node-id COUNTERS
    ZEROED
    and, depending on the speed events came in from the remote node often
    the getevent fired only once every 3 "counters zeroed".  After having
    played a lot, only sometimes we got the remote events immediately once
    these were issued.  Also we seem to feel that the freqency at which the
    events arrive influence the fact the events are lost or not, even if
    the frequency is not high, even if that's the only activity on the
    local system.  Does the implementation of DECmcc-to-DECnetSINKmonitor
    allows enough for queuing incoming events; is there any parameter which
    could be adapted to be sure no events are lost between DECnet and
    DECmcc ?
    
    These problems were the cause of this originally entry in the notes file.
    
    	Dominique.
                                                                    

    
    Can DECnet events be lost?
    
    Yeah, but it doesn't seem that the circumstances you describe should be
    causing events to be lost.  
    
    Both the DECmcc Event Manager, and DECnet's EVL will drop event reports
    if too many come in too quickly, but both are capable of handling a lot
    more event traffic than you appear to be sending.  The DECmcc Event
    Manager has data capacity on the order of hundreds of thousands of
    bytes of backed up reports.  EVL also has significant capacity.
    
    There are tuning parameters for the DECmcc Event Manager.  Right now,
    that is all hard coded.  Again, it looks like it should be plenty for
    your purposes.  Also, the DECmcc Event Manager has tested out as very good
    at recording the fact that an event report that should have been
    returned was thrown away for lack of space.  You would see that as an
    exception returned with your GETEVENT request.
    
    I scanned the VMS networking manuals and didn't find any knobs for fine
    tuning EVL's queues either.  I thought such tuning parameters existed,
    but I'm not sure what they are (were?).  Does anyone remember them?
    I couldn't find anything to adjust.
    
    So, no, there don't appear to be any adjustments, but that doesn't look
    at all like the problem you are running into.  You just don't appear to
    be stressing the system at anything near it's built in capacity.
    
    I am more worried that the events may not be getting delivered to
    DECmcc at all because of some other problem somewhere in the system. 
    This appears to be what is happening because we consistently report
    events that occur locally, and only get inconsistent results when the 
    events are remotely originated.
    
    We will spend some time here trying to reproduce your problem and
    characterize the problems you're seeing.
    
    You might try tuning the EVL process by increasing some of it's process
    quotas to see if that has any effect on the problem.  Let me know if
    you manage to mitigate or exaberbate the problem through this approach;
    we'll let you know what we find in our analysis.
    
    -Jim Carey
    
    
    
    

    If EVL wasn't rewritten for VMS V5.X, it still has max queue length
    of 10 unhandeled events. Changing any quotas wouldn't affect this
    hard-coded value.
    This was the choice taken in orginal Phase IV EVL for DECnet-VAX
    and implemented same way at least in VMS V4 code.
    
    Note that DNA Phase IV Network Management specification didn't specify
    implementation, only that events maybe lost and in such case I believe 
    that extra events would be dropped and Event 0.0 (Events Lost evet) 
    would be generated automatically.
    
    Olli