Conference azur::mcc

    Support for DECnet Phase IV events will not be in MCC V1.0.  Currently
    the architecture for MCC events and their support is being reviewed.
    
    From my understanding, you will be able to request an event from TRM.
    You may want to send mail to Jill Callander who is the TRM project
    leader.
    
    			Cindy
    

    Thank you 
    I will try to contact Jill
    Ciao
    			Giuseppina
    

    
    Okay I want to clarify some things, so we will start by defining
    some terms.
    
    There are a number of things that can happen, be generated, or be
    detected that the user might want to know about. These things are
    genericly termed OCCURRENCES. We will be supporting three types
    of OCCURRENCES, these are events, alarm triggerings, and messages.
    To access OCCURRENCES there will be a set of services known as
    notification services. These will allow the user to ask for specific
    types of OCCURRENCES, like events, or combinations of OCCURRENCES
    based upon the types and the entities that they apply to.
    
    Looking at the event type (since that is what you asked about),
    there are a few things to note. The user might want to receive
    notification of all events, specific events, or events on specific
    entities. They may also want to get notification only when a
    combination of events are detected within a time period, or when
    a specific event has occurred a specified number of times.
    
    The first set of cases call for a direct line from the event sink
    right to the display. And this is what we are shooting for, the
    shortest/quickest way to get the event, and display it to the user (based
    upon what events they are looking for) as an event occurrence. 
    
    In the second set of notifications some added intelligence is needed.
    For these we need another module (alarms) to keep track and signal when
    it has detected the condition (like a specific event on a specific node
    has been detected 5 times in the last hour). Since these require
    an alarm to be specified (not supported in V1) to look for and detect
    a condition based upon an event, these OCCURRENCES will be reported
    as alarm triggers instead of events. 
    
    To get the notification of these OCCURRENCES, notification services
    will include a specialized interface capable of handling the display
    of occurrences in a consistent/filterable fashion. This interface
    will also provide a full range of user interface functions to make
    the handling of large amounts of occurrence data a bit easier. This
    interface will be multi thread so as to handle the ability to request
    occurrence information on a number of types and entities from a
    single interface, with the data returned/displayed asynchronously
    and intermixed.
    
    On top of the notification services there will also be a method
    to get at event information through the standard screen based interface
    (MCC TRM). This will require the user to make a request to get the
    event data for a specific entity (or a wildcarded instance). This
    request will then remain outstanding, returning data back to the
    user interface for each detected event, until the user terminates
    the request using a CTRL/C or CTRL/Y. While the get event request
    is outstanding, no other requests can be made from that user session.
    

    ****
    
    Right now the notification services as described here are still
    in phase 1. We are hoping to close phase 1 soon. If you are interested
    I can post a pointer to the phase 1 documents, or send them to you.
    
    Does this answer your questions?
        

    
    
    Thanks you for your clear explanation.
    
    This is what i've looked for. 
    
    In any case, if you can, i 'd like to read the Allarm phase 1 document
    that you've mentioned (in order to get more details).
    
    Only another  question:
    
    Will be this new Allarm FM ( and new service interface) a general one
    for every entity accessed by different Access Module or not ?
    
    Will be utilized the CMIS M-Event Report Service or not ?
    
    Regards 
    
    			Giuseppina
        

Re .3:

I don't see any difference between an event report, an alarm triggering and
a message. I don't see why you need 3 different mechanisms/services to handle
what is essentially a single thing.

PS, your list of event, alarm triggering and message mixes apples and oranges.
Event is a "change of state", while an event report is a message/record that
describes a change in state (event reports are sometimes called notifications 
in ISO). But clearly the event, and the event report are very different things.
A message is just a special kind of event report. Something happened that caused
the message to be sent (that something was an event).An alarm triggering is just
a special kind of event. When it fires, it sends out something (I guess its 
called an alarm) which is a special kind of event report.

			Mark

    
    Mark,
    
    Don't let the mechanisms confuse you. As you stated the three "types"
    are all just different types of "events"; for this reason the
    notification services look to handle them all in the same manner.
    But...underlying implementation causes the notification FM to realize
    that the information is detected by different modules within the
    DECmcc system, and must therefore (unbeknownst to the user) be handled
    is different manners.
    
    jill
    

RE: .4    
    
> In any case, if you can, i 'd like to read the Allarm phase 1 document
> that you've mentioned (in order to get more details).
  
  There is no Alarms v1.1 Phase 1 document written at this time.  We're
  still busy wrapping up v1.0.  Ask again in a few weeks...
  
> Will be this new Allarm FM ( and new service interface) a general one
> for every entity accessed by different Access Module or not ?

  Alarms will always be generic!  It will be able to process events from any
  entity (through whatever access module) just as it processes any attribute.
    
> Will be utilized the CMIS M-Event Report Service or not ?
  
  Alarms will access events from management modules (either access or function)
  through a "show-like" directive that is currently being architected (and 
  developed).  This is an MCC-internal interface.  Each access module will 
  collect its events through whatever protocols are supported between it and
  its entity's agent.  

  I refer you to Mike (TOOK::) Densmore (Phase V DNA Access Module project
  leader) for a more detailed answer to your question.   

                                                                      - Jerry

    
    Things have gotten a bit confused here. There is a distinction between
    the services provided for alarming and those provided for receiving
    notification of occurrences from within DECmcc.
    
    As per off-line discussions it is my understanding that the use
    of "alarms" is not globally understood. .3 referenced notification
    services phase1 documents, not alarms fm documents. This pointer
    will be sent.
    
    

    I'm agree that in my answer .4 there was some confusions.
    So i try to be more clear (i hope):
    
    - like .3 as described, currently we don't have a complete 
      ALLARM FM : we can control only allarms based on the polling, but we
      can't control all the events that a generic entity (also from the EMA 
      model) could generate spontaneously (for example : DECnet phase IV
      and EVENT LOGGER)
     
      So i'd like to read phase 1 ALLARM FM for the next release (when 
      it will be available) in order to undestand well when and how we will
      have a complete ALLARM FM.
    
    - Assumed that we will have a  FM responsable of the reporting of allarms,
     errors and related informations in a "stantard fashion" (i'm not sure
     if it will be done by the ALLARM FM or REPORT FM), i'd like to know
     which kind of parameters will be used in this alarm reporting service.
     Will it be those are specified in CMIS EVENT-REPORT (ISO/IEC 9595)
     
    	-backup object istance
    	-backup status
    	-trend indication
      	-threshold information
    		triggered threshold
    		threshold level
    		observed value
    	        arm time
    	-notififcation identifier
    	-correlated notifications
    	-state change
    		old state
    		new state
    	-Monitored attributes
    	-proposed repair action
    	-problem text
    	-problem data
    	-current time
    	-event result
    	-errors
    
       or what ?
    
    THanks in advance
    
    				Giuseppina
    
    P.S.: of course, i'd like also to have the pointers to interesting
    documentation about it that you've mentioned.
    

    There currently isn't a V1.+ phase 1 document available for the
    Alarms FM. There phase 1 documents  available for the set of functions
    known as Notification Services. These documents can be found on:
    
    TOOK::USER$49:[MCC_ROOT.DOCUMENTATION]

    MCC$NOTIF_FUNCTIONAL_SPEC.LN3;1
    MCC$NOTIFICATION_PM_FS_DRAFT.LN3;1      
    MCC$WUI$CSFS_ADDENDUM.LN3;1             
    MCC$NOTIF_DEVELOPMENT_PLAN.LN3;2        
    MCC$NOTIF_PRODUCT_SPEC.LN3;1            

    These are the Module Reference Manual chapters that describe each
    of the internal call interfaces.
    
    MCC$NOTIFICATION_PM_MRM.LN3;1
    MCC$RULEBINDING_FM_MRM.LN3;2
    MCC$DATACOLLECTOR_AM_MRM.LN3;1          
    MCC$NOTIFICATION_FM_MRM.LN3;1

    Updates to these documents are currently in progress and should
    be available within the next few weeks, for phase 1 closure.
    
    jill Callander