Conference azur::mcc

    One thing I know is available now can be used by modifying your
    rules to include the logging automatically. Provided with the kit
    are a sampling of command procedures that can be called from the
    Alarms FM every time a rule fires (or misfires). These procedures
    are located in the MCC_COMMON directory. There is a procedure
    explicitly for the purpose of logging, this is call
    MCC_ALARMS_LOG_ALARMS.COM I believe. The user can set this up as
    the action procedure to be called when a rule fires. A default log
    file name is supplied (something like sys$login:mcc_alarms.log)
    but the user can set up their own log file location/name as they
    see fit by overriding the default.
    
    The uses for the alarms command procedures, as well as descriptions
    of the procedures that are supplied with the kit, are located in
    the MCC Alarms Use manual. Note that these procedures are examples
    (that do work) but that can also be customized to allow the user
    to initiate multiple actions from a single rule firing.
    

    Jim,
    
    Thanks for your reply.   I am quite happy that automatic logging of
    faults is available once they are detected.   How about automatic
    detection - or to be more precise - detection of faults without having
    to poll across the network for them.
    
    For instance if a link on a remote node goes down will there be some
    mechanism of 'sinking' the DECnet message to the network management
    system and triggering an alarm.
    
    JG
    

RE: .2

>> How about automatic detection - or to be more precise - detection of
>> faults without having to poll across the network for them.

Sorry, in DECmcc v1.1 there is no capability of 'Auto Rules'.


>> For instance if a link on a remote node goes down will there be some
>> mechanism of 'sinking' the DECnet message to the network management
>> system and triggering an alarm.

If there is an Event generated by DECnet when this happens .. you can 
write an Alarms Rule to monitor that event.  When the event occurs, the
information will be written to your log file (or mailed to you, etc...)

If there no event generated - then you can try the CHANGE_OF function.  This
will pole the entity/attribute at a rate you specify, and detect changes
in the value.

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

Example Rule Expression for an Event:

    Expression = (NODE4 WAKEME COUNTERS ZEROED)

  The default time specification for an Rule on an Event is 'forever'.
  ie, check this event forever, until I disable the rule.


Example Rule Expression for a Change of function:

    Expression = (CHANGE_OF(NODE4 WAKEME USER BYTES SENT,*,*))

  This rule will monitor the value of Node WAKEME's User Bytes Sent
  Attribute...If it changes, you will be notified (by the mechanism
  you select; Mail, Log file, Broadcast message, etc...).  The default
  time specification for a Rule on an Attribute is 'every 15 minutes.


Does this help ??

/Keith

>Example Rule Expression for an Event:
>
>    Expression = (NODE4 WAKEME COUNTERS ZEROED)
>
>  The default time specification for an Rule on an Event is 'forever'.
>  ie, check this event forever, until I disable the rule.

A typo in the above expression:

	The correct usage is:

	Expression = (OCCURS (NODE4 WAKEME COUNTERS ZEROED))

- Anil Navkal

    RE .2
    
    Boy some times I wonder around here...more people address notes
    to me as "Jim" than "Jill". I guess I should sign my notes
    more often.
    
    Anyway, did the stuff from Keith and Anil help clarify things? In
    the newest (EFT) releases of the AM Use manuals you will find that
    the events supported should be documented and their meanings explained.
    For a quick list of the event supported you can use the FCL FORMS
    mode. Do the following to get the list:
    
    MCC> USE MODE FORMS
    
    	<forms mode comes up>
    
    Verb:  GETEVENT
    Entity: <the entity class you are interested in>
    Arguments: <PF2>
    
    This will then look something like this:
    
          Verb: getevent
        Entity: node4 goste
     Arguments:
    Qualifiers:
                                List Of Valid Event IDs
        Event Records Lost
        Automatic Counters
        Counters Zeroed
        Local Node State Change
        Access Control Reject
        Node Cryptographic failure
        Invalid Message
        Invalid Flow Control
        Aged Packet Loss
        Any Events
    
    
    You can then use the Alarms FM "occurs" function to create a rule
    on any of these events.
    

    
    Thanks for all the input.   I am clear now on what can/cannot be done.   
    My prospective customer does not know much about EMA yet and they have
    said that management and ownership are key issues for them.   I reckon
    they will be pretty impressed with what we have on offer.
    
    Thanks again,                               
    
    JG
    
    P.S. Sorry about getting the name wrong Jill

    V1.0 of DECmcc did not provide event support. It was an item that
    we traded off for time to market. V1.1 DECmcc provides event support.
    Not all AMs have implemented an event logger but the kernel has
    implemented a central event log mechanism. There are a set of
    Notifications Services to distribute events to users asynchronously
    including alarms to the iconic map PM. The ALARMS FM supports
    asynchronous events at both its AM and FM interfaces. The DNA4
    AM provides events for V1.1. What is missing is events for DNA5
    (mostly because we have no real DNA5 event objects to test against),
    SNMP, etc. Bridges do not generate events so there is no event
    support in the Bridge AM.
    
    I hope this answers your concerns.
    
    wally

I am working on requirements for automated network fault isolation and 
recovery techniques for a smart hub project.  I am interested in finding
out what work has been done in these areas either inside or outside of mcc.
If there is somewhere else where I should inquire please let me know.

Thanks in advance,

Bob