Conference azur::mcc

    
    Okay, to start with only rules can cause an icon to turn a color.
    To get a phase IV event to do this make use of the OCCUR function
    in the rule expression, generating a rule fired event when the event
    occurs, this will turn the icon a color.
    
    To get the event collector running I can only speak from my own
    experience. The problems I encountered were: I didn't have a task 
    0 defined, I was trying to start it up from my prived account which
    DIDN'T have default privs (I only had setprv) to access the default
    directory assigned to the account (so the process failed trying
    to write the dna4 log file). After fixing these two conditions (I
    finally just did it from the system account, I could get things
    going. I it is easy to see if everything is there just start it
    up, check to see if the process is running, and then zero the counters
    on a node4 line or circuit and see if you get the event (to do this
    from one FCL session you will have to use the notify directive).
    
    As to the accvios I haven't seen any recently but the original EFT
    kit had quite a few in the cases where the notify threads were
    attempting to shut down after user requested termination. I hadn't
    seen any in the getevent support.
    
    jill
    

The Alarms FM supports the detection of Events from any other Management
Module (ie, DECnet Phase 4)

You must create a Rule using the OCCURS function, where the expression would
look like:

	(OCCURS(NODE4 WAKEME COUNTERS ZEROED))

The default time specification for a Rule on an Event is << Forever >>

You can use the scope-of-interest time syntax to modify that:

	(OCCURS(NODE4 WAKEME COUNTERS ZEROED), FOR DURATION 01:00:00)

This example says to 'watch' for the Event for 1 Hour after the Rule
has been enabled.

When the Rule fires, the Icon will change color (Of course, you must be
running the Iconic Map - and Enable Notification via the FILE pull-down
menu).

Keith
DECmcc Alarms Team

    
    To make sure that you're successfully collecting DECnet events, I'd
    say to try the GETEVENT directive directly from FCL.  This cuts all the
    middlemen out of the loop while  you ascertain that DECnet is set up
    correctly.
    
    If you are familiar with event collection through NCP, then you've
    already run into the kinds of things that you're about to run into
    again.
    
    Look at SYS$STARTUP:MCC_STARTUP_DNA4_EVL.COM.  This procedure sets up
    EVL and MCC to collect events, and will start up the monitor process
    MCC_DNA4_EVL to monitor events and deposit them for DECmcc consumption.
    
    It is configured to enable all event reports from all sources that
    occur to your local node or one of its child entities (like its
    circuits and lines).
    
    To be successful with it, the account you run it out of will need the
    following default privileges:  SYSNAM,DETACH,TMPMBX,NETMBX.  We need
    these to successfully initiate the MCC_DNA4_EVL process, and to connect
    with EVL.
    
    Once done, all events occurring on your node will be sent to the DECmcc
    monitor sink process.  These are discarded by DECmcc unless you have 
    outstanding GETEVENT requests (directly, or via the NOTIFY function or
    an ALARMS rule).
    
    So, make a GETEVENT request.  A good test is to watch for node4
    counters zeroed, or automatic counters.  If you want Automatic
    counters, use DECmcc to set the counter timer.  A counters zeroed event
    will occur if you just zero the counters from another process.
    
    
    In one process, run DECmcc:
    
    MCC> GETEVENT NODE4 mynode Remote node mynode remote node counters zeroed
    
    This will go away and not come back, until:
    
    In another process, run DECmcc:
    
    MCC> ZERO NODE4 mynode
    
    When you have set up event logging correctly, then the GETEVENT in 
    process one will complete and dump out an event with a list of the
    counters as they were before the counters were zeroed.
    
    Unfortunately you must specify the Remote Node in the getevent request 
    because EVL delivers the event as though it happened to a remote node
    even though it is the executor.
    
    That is another long discussion.  For V1.1 this is a restriction to the
    behavior of GETEVENT.
    
    Once you have that side working, then NOTIFY and OCCURS can be checked
    out relatively quickly.
    
    -Jim
    

    Thanks for the suggestions, but most of these things never were a
    problem!
    
    .3 looks promising, I don't think I was specifying remote in the
    getevent, and certainly it never completed. Also, since I have had
    several ACCVIOs I think I will check my kit vintage.
    
    If I turn up anything significant I'll post it back,
    
    :-)
    Ken