Conference azur::mcc

Hello !

I have new questions dealing with the COLLECTOR AM;
I shall here continue the list of questions started in .0
I would be very grateful if someone could provide them with
an answer.

Backround information:

Please refer to .0


Questions:

1) to 8) Please refer to .0
9)       I clearly understand the goal of the procedure
         sys$startup:mcc_startup_evc_sink.com. However,
	 I also found a procedure mcc_system:mcc_evc_sink.com.
	 The only command that this procedure issues is
	 "$ manage/enterprise/presentaion=mcc_evc_sink"
	 What is the role of this procedure ? By whom,
	 By when is it executed ?
10)	 With the experiment explained in .0, I checked
	 that the delivered image mcc_evc_send.exe exit
	 with an error status when no collector sink process
	 is present... fine !
	 Now, if the sink process is present but if no DECmcc
	 session is active, the image mcc_evc_send.exe does
	 not exit with an error status: the event has been
	 passed to the sink. However, since there are no
	 DECmcc session active, the event is not logged
	 or reported anywhere. Therefore, there is a potential
	 lost of events. Any work-around ?
   

In adance, thank you for your answers,

Maurice.

    okay, before getting into the guts of you question, lets review 
    some misconceptions.
    
    
    1 reference entity
    1 collector entity
    
    1 notify on ANY EVENT
    	
    1 rule on the *collector* entity
    
    The rule will turn the collector a color; alarms does NOT know how
    to interpret the collector event data; only the notification PM does.
    To turn the reference entity a collor on this type of a rule you would
    have to assign a target for the rule.
    
    The notify command you created is for ANY EVENT, which means it will
    be looking for the rule events as well as the events on any other
    entity in the domain, which means it is also looking for the collector
    events. This is why you see the "event" twice. In reality you are
    seeing the collector event, and you are seeing the rule event (two
    seperate things that are tied together based on the fact that the rule
    is monitoring the same event you told the notify to watch).
    
    The notification services knows how to interpret the target entity
    information you supplied on the data collector event that is why it is
    capable of turning the reference entity a color.
    
    With that background let's go over the questions.
    

Questions:
    
1) It is not possible to create an alarm rule on a reference entity; is
   it a supported feature or a bug in the FT7 version ?
    
        You can create a rule on a reference entity, it is just that
        reference entities only support attributes and they do NOT support 
    	events. Your event is on the collector entity, which you have 
        targetted to turn the reference entity a color.
    
    DECmcc (T1.2.7)
    
    MCC> create domain ref
    
    Domain LOCAL_NS:.ref
    AT 20-MAY-1992 08:55:23
    
    Create Successful
    MCC> register ref testref
    
    Reference LOCAL_NS:.testref
    AT 20-MAY-1992 08:55:31
    
    Registration successful.
    MCC> create domain ref member testref
    
    Domain LOCAL_NS:.ref Member LOCAL_NS:.testref
    AT 20-MAY-1992 08:55:39
    
    Create Successful
    MCC> notify domain ref
    %MCC-S-NOTIFSTART, Notify request 1 started
    MCC> set ref testref location ="test ref"
    
    Reference LOCAL_NS:.testref
    AT 20-MAY-1992 08:57:39 References
    
    Modification(s) completed successfully.
                                   Location = "test ref"
    MCC> create domain ref rule ref exp=(ref testref location = "test ref")
    
    Domain LOCAL_NS:.ref Rule ref
    AT 20-MAY-1992 08:57:54
    
    Rule created and enabled successfully.
    MCC>
    !!!!!!!!!!!!!! Alarm, 1992-05-20-08:57:07. !!!!!!!!!!!!!! [1]
    Domain: LOCAL_NS:.ref                                 Severity:
    Indeterminate
    Notification Entity: Reference LOCAL_NS:.testref
    Event Source: Domain LOCAL_NS:.ref Rule ref
    Event: OSI Rule Fired
    
                                 Event Type = QualityofServiceAlarm
                                 Event Time = 1992-05-20-08:57:06.184
                             Probable Cause = Unknown
                            Additional Info = { (
                                   significance = True,
                                    information = "Rule fired: Reference
                                                  LOCAL_NS:.testref
    Location =
                                                  ""test ref""
                                                  1992-05-20-08:57:06.105"
    ),
                                                (
                                   significance = True,
                                    information = "(ref testref
    location=""test
                                                  ref"")" ) }
                             Managed Object = Reference LOCAL_NS:.testref
                         Perceived Severity = Indeterminate
                                        
2) I have noticed that the icons, the severity field in the notification window
       and the severity field in the Notification Detail management window
       do not exhibit the correct color for an event whose severity is not
    "critical".
       However, the severity is correctly propagated in the notification
    log file and
       in the graph window. Is it a supported feature or a bug in the FT7 version ?
    
    I am not sure on this one what you are seeing for a problem. There are
    some known problems in the T1.2.7 kit when clearing a higher severity
    notificatoin on an entity, the lower severity is not properly
    propogated up to replace the deleted/reset notification. If this isn't
    what you mean you will have to clarify.
    
3) The Notification window and the Notification log file shows two notification
(alarm)
   events per configuration event sent... however, only one mail
   is sent per configuration event by the fired rule command procedure.
   Why are there TWO alarms fired and why is there only ONE mail ?
    
    These two are due to the fact that you seem to have started two notify
    commands and not one. The numbers in the parens are the 
    	[notify command unique id, the # of the event given by the PM]
    you can see that your events are coming in on NOTIFY request number
    2 and 3.
    
Alarm:  critical    Collector SDE:.MC_COLLECTOR Rule ANY_EVENT_ON_COLLECTOR_OCCURED
has fired   18-MAY-1992 13:35:53.07 Domain SDE:.MC_MCC  [2,3]
    Info1: The last event detected: Collector SDE:.MC_COLLECTOR General Event  18-MAY-1992 13:35:50.32
    Info2: Event: General Event ""EVENT1""  Event Text = ""First Event on Collector""
    Info3: (OCCURS (Collector SDE:.mc_collector  Any Event))
    Text: Test Any Event On Collector Description
Alarm:  critical    Collector SDE:.MC_COLLECTOR Rule ANY_EVENT_ON_COLLECTOR_OCCURED
has fired   18-MAY-1992 13:35:53.26 Domain SDE:.MC_MCC  [3,4]
    Info1: The last event detected: Collector SDE:.MC_COLLECTOR General Event  18-MAY-1992 13:35:50.32
    Info2: Event: General Event ""EVENT1""  Event Text = ""First Event on Collector""
    Info3: (OCCURS (Collector SDE:.mc_collector  Any Event))
    Text: Test Any Event On Collector Description
  :
Alarm:  critical    Collector SDE:.MC_COLLECTOR Rule ANY_EVENT_ON_COLLECTOR_OCCURED
has fired   18-MAY-1992 13:35:57.86 Domain SDE:.MC_MCC  [2,6]
    Info1: The last event detected: Collector SDE:.MC_COLLECTOR General Event  18-MAY-1992 13:35:56.00
    Info2: Event: General Event ""EVENT2""  Event Text = ""Second Event on Collector""
    Info3: (OCCURS (Collector SDE:.mc_collector  Any Event))
    Text: Test Any Event On Collector Description
Alarm:  critical    Collector SDE:.MC_COLLECTOR Rule ANY_EVENT_ON_COLLECTOR_OCCURED
has fired   18-MAY-1992 13:35:58.23 Domain SDE:.MC_MCC  [3,7]
    Info1: The last event detected: Collector SDE:.MC_COLLECTOR General Event  18-MAY-1992 13:35:56.00
    Info2: Event: General Event ""EVENT2""  Event Text = ""Second Event on Collector""
    Info3: (OCCURS (Collector SDE:.mc_collector  Any Event))
    Text: Test Any Event On Collector Description

4) For the events targetted on the reference entity (POD_2), the Notification
   window, the Notification Detail management window and the notification log
file
   exhibit the targetted entity for the configuration events; however, the
targetted
   entity is not displayed for the notification (alarm) events neither in the
   Notification window/log file nor in the mails sent by the fired rule command
procedure.
   Is there any mean to display the targetted entity in the notification
window/log file ?
   Is there any mean to capture the targetted entity as a parameter for the
Alarm command
   Procedure ?

    The targeting information on the rule that you are talking about should show
    up in the mail as a piece of data on the collection event, and not as a
    target entity. If you want to target the rule fire, that is independent of
    the collection event targetting. But, it isn't there, and that is a problem
    with alarms dropping the data. Alarms only returns the event and not the
    associated targetting information on the event. I have qared this.
    	MCC_INTERNAL #3033
    
5) To my understanding, the collector AM event sink is a detached process using
   transparent task to task communication ... is this correct ?

    yup.
    
6) Does the DECmcc collector AM event sink requires/sets the task object to
"enabled" ?
   In the affirmative, will this be changed in the released version of
   DECmcc 1.2 since this violates the Corporate Security Standards V11.1 ?
    
    sorry, I don't know enough about it. But mine looks like:
    NCP>show known objects
    	:
      MCC_DNA4_EVL
                     0  20401204
      MCC_EVC_SINK
                     0  204015DE
      TASK           0
    

7) In order to start the Collector AM Event sink, the "starter" needs a
   proxy on his own account. Is this correct ?
   In the affirmative, will this be changed in the released version of
   DECmcc 1.2 since this violates the Corporate Security Standards V11.1
   (no proxies from privileged account) ?

    You need the same *DEFAULT* privs to start this sink as you do to start the
    dna4 EVL sink. These are (from the mcc_startup_dna4_evl.com comments):
    	$!      1.  Must have default privileges: TMPMBX,NETMBX,DETACH,SYSNAM
    
    To then use the collector, you don't need any proxy that I know of. Here,
    DORIOT has no proxy into goste...
    
    
    DORIOT$ snd :=="$USER$216:[CALLANDER]MCC_EVC_SEND.EXE "
    DORIOT$ snd  goste test "node4 goste" "test" "test text" warning
    DORIOT$
    
    --on GOSTE--
    MCC> enable mcc 0 coll sink decnet
    
    MCC 0 COLLECTION_AM SINK DECnet
    AT 20-MAY-1992 11:03:36
    
    Enable completed successfully.
    MCC> notify domain ref ent list=(coll *), eve=(any confi event)
    %MCC-S-NOTIFSTART, Notify request 2 started
    MCC> display notify
    
    Notify requests currently in progress:
    
    Entry  Status   Command
    -----  ------   -------
        2  Running  notify domain ref ent list=(coll *), eve=(any confi event)
    
    MCC>
    MCC> getevent coll test any config event
    
    %%%%%%%%%%%%%% Event, 20-MAY-1992 11:07:52 %%%%%%%%%%%%%% [2]
    Domain: LOCAL_NS:.ref                                 Severity: Warning
    Notification Entity: Node4 LOCAL_NS:.goste
    Event Source: Collector LOCAL_NS:.test
    Event: General Event
    "test"
                                 Event Text = "test text"
    
    
    Collector LOCAL_NS:.test
    AT 20-MAY-1992 11:05:58 CONFIGURATION EVENTS
    
                              Target Entity = Node4 goste ,
                            Target Severity = warning,
    Event: General Event
    "test"
                                 Event Text = "test text"
    MCC>
    
    
8) The  collector AM event sink detached process is of crutial importance
   for the events transmission. Therefore, we would like to be aware when, for
   any reason, this process dies. Would it be possible to do this check using
   DECmcc ? In the affirmative, have you any hint ?
    
    you bet, monitor the object:
    
Rule created and enabled successfully.
MCC> display notify

Notify requests currently in progress:

Entry  Status   Command
-----  ------   -------
    2  Running  notify domain ref ent list=(coll *), eve=(any confi event)

MCC> notify domain ref even=(any notif event)
%MCC-S-NOTIFSTART, Notify request 3 started
MCC> display notify

Notify requests currently in progress:

Entry  Status   Command
-----  ------   -------
    2  Running  notify domain ref ent list=(coll *), eve=(any confi event)
    3  Running  notify domain ref even=(any notif event)

MCC> disable mcc 0 coll sink decnet

MCC 0 COLLECTION_AM SINK DECnet
AT 20-MAY-1992 11:17:35

Disable completed successfully.
MCC>

!!!!!!!!!!!!!! Alarm, 20-MAY-1992 11:17:53 !!!!!!!!!!!!!! [3]
Domain: LOCAL_NS:.ref                                 Severity: Indeterminate
Notification Entity: Node4 LOCAL_NS:.goste Object MCC_EVC_SINK
Event Source: Domain LOCAL_NS:.ref Rule test_status
Event: OSI Rule Exception

                             Event Type = QualityofServiceAlarm
                             Event Time = 20-MAY-1992 11:17:51.87
                         Probable Cause = Unknown
                        Additional Info = { (
                               significance = True,
                                information = "No such entity: Node4 0 Object
                                              MCC_EVC_SINK " ),
                                            (
                               significance = True,
                                information = "(node4 0 object MCC_EVC_SINK
                                              number <> 0, at every ::30)" ) }
                         Managed Object = Node4 4.507 Object MCC_EVC_SINK
                     Perceived Severity = Indeterminate


MCC>enable mcc 0 coll sink decnet
                                     
MCC 0 COLLECTION_AM SINK DECnet
AT 20-MAY-1992 11:18:38

Enable completed successfully.
MCC>

!!!!!!!!!!!!!! Alarm, 20-MAY-1992 11:18:52 !!!!!!!!!!!!!! [3]
Domain: LOCAL_NS:.ref                                 Severity: Clear
Notification Entity: Node4 LOCAL_NS:.goste Object MCC_EVC_SINK
Event Source: Domain LOCAL_NS:.ref Rule test_status
Event: OSI Rule Fired

                             Event Type = QualityofServiceAlarm
                             Event Time = 20-MAY-1992 11:18:51.86
                         Probable Cause = Unknown
                        Additional Info = { (
                               significance = True,
                                information = "Rule cleared: Node4 4.507 Object
                                              MCC_EVC_SINK Number = 0
                                              20-MAY-1992 11:18:51.83" ),
                                            (
                               significance = True,
                                information = "(node4 0 object MCC_EVC_SINK
                                              number <> 0, at every ::30)" ) }
                         Managed Object = Node4 4.507 Object MCC_EVC_SINK
                     Perceived Severity = Clear


MCC> spawn stop proc/id=20400F11
MCC>

!!!!!!!!!!!!!! Alarm, 20-MAY-1992 11:19:52 !!!!!!!!!!!!!! [3]
Domain: LOCAL_NS:.ref                                 Severity: Indeterminate
Notification Entity: Node4 LOCAL_NS:.goste Object MCC_EVC_SINK
Event Source: Domain LOCAL_NS:.ref Rule test_status
Event: OSI Rule Exception

                             Event Type = QualityofServiceAlarm
                             Event Time = 20-MAY-1992 11:19:51.93
                         Probable Cause = Unknown
                        Additional Info = { (
                               significance = True,
                                information = "No such entity: Node4 0 Object
                                              MCC_EVC_SINK " ),
                                            (
                               significance = True,
                                information = "(node4 0 object MCC_EVC_SINK
                                              number <> 0, at every ::30)" ) }
                         Managed Object = Node4 4.507 Object MCC_EVC_SINK
                     Perceived Severity = Indeterminate


MCC>

9)       I clearly understand the goal of the procedure
         sys$startup:mcc_startup_evc_sink.com. However,
	 I also found a procedure mcc_system:mcc_evc_sink.com.
	 The only command that this procedure issues is
	 "$ manage/enterprise/presentaion=mcc_evc_sink"
	 What is the role of this procedure ? By whom,
	 By when is it executed ?
    
    don't know, I will have to ask around but my guess is that the startup evc
    sink process uses it. Because this is the commnad for getting it
    going.
    
    
10)	 With the experiment explained in .0, I checked
	 that the delivered image mcc_evc_send.exe exit
	 with an error status when no collector sink process
	 is present... fine !
	 Now, if the sink process is present but if no DECmcc
	 session is active, the image mcc_evc_send.exe does
	 not exit with an error status: the event has been
	 passed to the sink. However, since there are no
	 DECmcc session active, the event is not logged
	 or reported anywhere. Therefore, there is a potential
	 lost of events. Any work-around ?
   
    There is always the potential that events will be lost, like a sink up and
    no MCC to recieve them. But the sender does get errors if the sink is
    disabled when the attempt to send the event.
    
    
    DORIOT$ snd  goste test "node4 goste" "test" "test text" warning
    %SYSTEM-F-INVLOGIN, login information invalid at remote node
    
    The only easy "work-around" is that you disable your sink if you don't have
    a log/user running.
    
    
    Hope this helps.
    jill
    

Hi Maurice,

	Since Jill already answered most of your questions (thanks, Jill),  
I will just add a few points to her answers.

...
    
5) To my understanding, the collector AM event sink is a detached process using
   transparent task to task communication ... is this correct ?
   ^^^^^^^^^^^
>>   NON-transparent task to task communication.
    
6) Does the DECmcc collector AM event sink requires/sets the task object to
   "enabled" ?
   In the affirmative, will this be changed in the released version of
   DECmcc 1.2 since this violates the Corporate Security Standards V11.1 ?
    
>>  NOT for VMS V5.4 and later systems.    


9)       I clearly understand the goal of the procedure
         sys$startup:mcc_startup_evc_sink.com. However,
	 I also found a procedure mcc_system:mcc_evc_sink.com.
	 The only command that this procedure issues is
	 "$ manage/enterprise/presentaion=mcc_evc_sink"
	 What is the role of this procedure ? By whom,
	 By when is it executed ?
    
>>	mcc_evc_sink.com is ONLY invoked by Collector AM, users do NOT 
>>	need to do anything about it.  If you are really curious about
>>	it, it is invoked when Collector AM creates the sink process using
>>	sys$creprc().  It's strictly used by MCC internally.    
    
10)	 With the experiment explained in .0, I checked
	 that the delivered image mcc_evc_send.exe exit
	 with an error status when no collector sink process
	 is present... fine !
	 Now, if the sink process is present but if no DECmcc
	 session is active, the image mcc_evc_send.exe does
	 not exit with an error status: the event has been
	 passed to the sink. However, since there are no
	 DECmcc session active, the event is not logged
	 or reported anywhere. Therefore, there is a potential
	 lost of events. Any work-around ?
   
>>	Yes, as Jill replied, it's possible when the sink is not up when
>>	your application sends data.  The SEND application will get one
>>	of many possible messages, depending on what stage the receiving
>>	system (DECmcc) is in.  In Jill's reply, "invalid login information"
>>	is one of them.  
>>	To better handle this situation, 1) we can put some enahancement in 
>>	the future SEND application to better display error messages.
>>	or 2) you can put in some error handling in your application that calls
>>	mcc_evc_send.  For example, before you send, you can use MCC command
>>	to show whether the receiving MCC station has a object mcc_evc_send
>>	active.
    
	Hope all these suggestions and answers help.

	Jean
	

Jill and Jean,

Thank you very much for your answers and clarifications.
    They already helped me a lot.

Still, I have a few open topics.
    
    
>    1 reference entity
>    1 collector entity
>    
>    1 notify on ANY EVENT
>    	
>    1 rule on the *collector* entity

More precisely:
  1 domain (MC_MCC) containing:
    1 reference entity (POD_2)
    1 collector entity (MC_COLLECTOR)
    
  2 notify requests on ANY EVENT:
     - Notify Domain MC_MCC Entity List = (Collector *), Events = (Any Events)
     - Notify Domain MC_MCC Entity List = (Reference *), Events = (Any Events)
  1 rule on the *collector* entity
      Create MCC 0 ALARMS RULE ANY_EVENT_ON_COLLECTOR_OCCURED  -
        Category           = "Test Any Event On Collector", -
        Description        = "Test Any Event On Collector Description", -
        Expression         = (OCCURS (Collector SDE:.mc_collector  Any Event)), -
        Procedure          = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_ALARM.COM;2, -
        Exception Handler  = SYS$COMMON:[MCC]MCC_ALARMS_MAIL_EXCEPTION.COM;2, -
        Parameter          = "Player::colleye", -
        Queue              = "tplab$batch", -
        Perceived Severity = Critical, -
        Probable Cause     = Unknown, -
        in domain = SDE:.MC_MCC    	
    
>    The rule will turn the collector a color; alarms does NOT know how
>    to interpret the collector event data; only the notification PM does.
>    To turn the reference entity a collor on this type of a rule you would
>    have to assign a target for the rule.

   This is (was) clear to me, but...
    - on one hand, I did not succeed to create an alarm rule for
      a reference entity (see below)
    - on the other hand, I had no doubt about which DECmmc management
      module (notification FM) is responsible for requesting the Iconic 
      Map PM to change the color of icons in a map window or fields in
      the notification window. What I noticed is that, despite my customization
      specifies (Customization - Map Severities Color) different colors for
      the different severities (Red for critical, Orange for major...), when
      an event occurs (wether it is a notification event or a configuration
      event), if the event severity is critical, icons/fields are
      turned to read but if the event is of any other severity than critical
      the icons/fields are turned to black. It might be well possible this
      is a limitation of the hardware I am using (a VAXstation 2000 -
      color monitor - used as an EWS (V1.1) terminal connected to a
      VAX 6000-430, running VMS 5.5 and DECwindow/Motif)
    
>    The notify command you created is for ANY EVENT, which means it will
>    be looking for the rule events as well as the events on any other
>    entity in the domain, which means it is also looking for the collector
>    events. This is why you see the "event" twice. In reality you are
>    seeing the collector event, and you are seeing the rule event (two
>    seperate things that are tied together based on the fact that the rule
>    is monitoring the same event you told the notify to watch).
 
     What I see in the notification window (and this is reflected in the
     notification log file in .0) is: for any event,
     - 1 configuration event (with a up-arrow)
     - 2 alarm events (with a bell)
     Thus I see 3 things and my question is/was why 2 alarm events ?
    
>    The notification services knows how to interpret the target entity
>    information you supplied on the data collector event that is why it is
>    capable of turning the reference entity a color.
>
>    
>    With that background let's go over the questions.
    
     Okay...

Questions:
    
1) It is not possible to create an alarm rule on a reference entity; is
   it a supported feature or a bug in the FT7 version ?
    
>        You can create a rule on a reference entity, it is just that
>        reference entities only support attributes and they do NOT support 
>    	 events. Your event is on the collector entity, which you have 
>        targetted to turn the reference entity a color.
         [...]
   Thank you... I am now convinced we can create an alarm rule for the FCL PM.
   On the other hand, I tried with the Iconic Map PM. It failed:
   a "create entity" window appears and displays the message "Valid
   entity not found"
   In the rule definition window, the entity I had specified was:
   REFERENCE POD_2
   The "Valid entity not found" message, despite the specified entity was
   registered, brought me to the conclusion that it was not possible to 
   create an alarm rule on a reference entity.
   So, what is the conclusion ?
   
                                        
2) I have noticed that the icons, the severity field in the notification window
   and the severity field in the Notification Detail management window
   do not exhibit the correct color for an event whose severity is not
   "critical".
   However, the severity is correctly propagated in the notification
   log file and in the graph window. 
   Is it a supported feature or a bug in the FT7 version ?
    
>    I am not sure on this one what you are seeing for a problem. There are
>    some known problems in the T1.2.7 kit when clearing a higher severity
>    notificatoin on an entity, the lower severity is not properly
>    propogated up to replace the deleted/reset notification. If this isn't
>    what you mean you will have to clarify.

   I am not too sure of understanding of what you mean by "clearing a higher 
   severity notification" or by "the deleted/reset notification". 
   Therefore, the clarification of what I am seeing for a problem is provided
   before this lonnnnnnnnnng list of questions.
   On the other hand, I would be very grateful if you could provide me
   with a pointer where I can find an explanation of the known problem in the 
   T1.2.7 kit when clearing a higher severity notification.
    
3) The Notification window and the Notification log file shows two notification
   (alarm) events per configuration event sent... however, only one mail
   is sent per configuration event by the fired rule command procedure.
   Why are there TWO alarms fired and why is there only ONE mail ?
    
>    These two are due to the fact that you seem to have started two notify
>    commands and not one. The numbers in the parens are the 
>    [notify command unique id, the # of the event given by the PM]
>    you can see that your events are coming in on NOTIFY request number
>    2 and 3.
     [...]    
   Given the clarification above the questions, I still do not see how I
   could achieve my goal:
   I would like to receive in the notification window ONE row with an up
   arrow for any configuration event (whether this event is for the
   collector entity or targetted to a reference entity) and to additionally
   receive ONE row with an alarm bell if an alarm rule 
   (OCCURS (Collector/Reference <collector/reference_entity_name> Any Event) 
   is fired.
   Which notify request should I create/enable ?

4) For the events targetted on the reference entity (POD_2), the Notification
   window, the Notification Detail management window and the notification log
   file exhibit the targetted entity for the configuration events; however, the
   targetted entity is not displayed for the notification (alarm) events 
   neither in the Notification window/log file nor in the mails sent by the 
   fired rule command procedure.
   Is there any mean to display the targetted entity in the notification
   window/log file ?
   Is there any mean to capture the targetted entity as a parameter for the
   Alarm command Procedure ?

>    The targeting information on the rule that you are talking about should show
>    up in the mail as a piece of data on the collection event, and not as a
>    target entity. If you want to target the rule fire, that is independent of
>    the collection event targetting. But, it isn't there, and that is a problem
>    with alarms dropping the data. Alarms only returns the event and not the
>    associated targetting information on the event. I have qared this.
>    	MCC_INTERNAL #3033
    
     Thank you for the QUAR... let's wait ! Question closed for the time being.
    
5) To my understanding, the collector AM event sink is a detached process using
   transparent task to task communication ... is this correct ?

>    yup.

   Received loud and clear... 5/5; question closed !
    
6) Does the DECmcc collector AM event sink requires/sets the task object to
   "enabled" ?
   In the affirmative, will this be changed in the released version of
   DECmcc 1.2 since this violates the Corporate Security Standards V11.1 ?
    
>    sorry, I don't know enough about it. But mine looks like:
>    NCP>show known objects
>    	:
>      MCC_DNA4_EVL
>                     0  20401204
>      MCC_EVC_SINK
>                     0  204015DE
>      TASK           0

   The Alarms and Notifications Services Use manual - field test update -
   states (parag. Starting the Collector AM event sink) "Prior starting
   the Collector AM, ensure you have the following default privileges:
   [...]. ALSO, THE TASK OBJECT MUST BE ENABLED"
   Two possibilities:
   - the documentation is in error and DECmcc does not require/set the
     task object to enabled
   - the documentation is not in error but then this will offend a lot
     of system managers concerned by the security of their system.
   I would be very gratefull if you would accept make some investigation
    

7) In order to start the Collector AM Event sink, the "starter" needs a
   proxy on his own account. Is this correct ?
   In the affirmative, will this be changed in the released version of
   DECmcc 1.2 since this violates the Corporate Security Standards V11.1
   (no proxies from privileged account) ?

>    You need the same *DEFAULT* privs to start this sink as you do to start the
>    dna4 EVL sink. These are (from the mcc_startup_dna4_evl.com comments):
>    	$!      1.  Must have default privileges: TMPMBX,NETMBX,DETACH,SYSNAM
>    
>    To then use the collector, you don't need any proxy that I know of. Here,
>    DORIOT has no proxy into goste...
>    
[...]
    Note 2790.7 -< DECnet PhazeIV Event Sink workaround... >-
    states that
       "Also everyone else trying to start up the phaze-iv event sink...
        Below is a modified startup file like the one which comes with
        the kit. I have found that by setting the mcc_dna4_am_log bit in the
        bms and dir startup command procedures we have run into a small got'cha'.
        There are 2 work arounds...
        ( 1 ) The account that you start up the phaze-iv sink from
              must have proxy to itself.
              --- example ---
              $ set def sys$system
              $ run authorize
              UAF> add/proxy local_node::decmcc_account_name privileged_account
              UAF> exit
              $@sys$startup:mcc_startup_dna4_evl
        ( 2 ) simply modify the startup procedure below and run it. [...]"

    I was just wondering if the same work-around was needed for the Collector
    AM sink and if the affirmative if this would be corrected for the released
    version.
    
    
    
8) The  collector AM event sink detached process is of crutial importance
   for the events transmission. Therefore, we would like to be aware when, for
   any reason, this process dies. Would it be possible to do this check using
   DECmcc ? In the affirmative, have you any hint ?
    
>    you bet, monitor the object:
   [...]
   Thank you for you hint... I think that it is not cibled enough to
   the specific object I want to monitor (and will lead to a lot of events
   to be trapped)
   I would like to create an alarm rule to detect that the collector 
   sink is down.
   I tried to create an alarm rule for the entity 
   MCC 0 Collection_am SINK decnet.
   As in question 1, I cannot through the Iconic Map... what can I try next ?
  
    

9) I clearly understand the goal of the procedure
   sys$startup:mcc_startup_evc_sink.com. However,
   I also found a procedure mcc_system:mcc_evc_sink.com.
   The only command that this procedure issues is
   "$ manage/enterprise/presentaion=mcc_evc_sink"
   What is the role of this procedure ? By whom,
   By when is it executed ?
    
>    don't know, I will have to ask around but my guess is that the startup evc
>    sink process uses it. Because this is the commnad for getting it
>    going.

   Let's wait...
         
    
    
10)With the experiment explained in .0, I checked
   that the delivered image mcc_evc_send.exe exit
   with an error status when no collector sink process
   is present... fine !
   Now, if the sink process is present but if no DECmcc
   session is active, the image mcc_evc_send.exe does
   not exit with an error status: the event has been
   passed to the sink. However, since there are no
   DECmcc session active, the event is not logged
   or reported anywhere. Therefore, there is a potential
   lost of events. Any work-around ?
      
>    There is always the potential that events will be lost, like a sink up and
>    no MCC to recieve them. But the sender does get errors if the sink is
>    disabled when the attempt to send the event.
>    
>    
>    DORIOT$ snd  goste test "node4 goste" "test" "test text" warning
>    %SYSTEM-F-INVLOGIN, login information invalid at remote node
>    
>    The only easy "work-around" is that you disable your sink if you don't have
>    a log/user running.
    
     Thank you.

Hello, I've got an other question to the COLLECTOR AM:

Are there Send_EVENT programs under Ultrix and DOS like we have under VMS? If 
no, is the interface public to code own ones? How big would be the manpower 
to do that?

Roland

Roland, 

The mcc_evc_send program (and API) is shipped as SOURCE code so that
enterprising folk can take it, modify it or port as they like (or need, in oyur
case)...   The same code is shipped on Ultrix and VMS. (the example just has a
couple of of  #ifdef's to handle the differences between the O/S.

As long as you have access to DECnet routines on your system, porting should be
trivial.   I haven't looked into DECnet-DOS; not enough time to ramp myself up
on a DOS programming environment.   If you know of anyone with experience in
programming DECnet-DOS applications, they should be able to modify the API code
enough to work in a DOS environment.

gday
/doug

On our (well-INSPECTed) systems we have the TASK object defined with a
User Id of ILLEGAL and Password of DISABLED.

There is no Username ILLEGAL.

This seems to satisfy INSPECT and our Collector works!

_Mek

I am trying to understand how the data collector works, but without much 
success so far. Maybe someone can explain what I am doing wrong.

In brief , this is what I did: Followed all the steps as mentioned in the 
manual and in the previous notes like : defining object, enable sink, define
collector, define symbol. Than when I send a message from DCL nothing happens.

Here follows the log..


VMS 5.5 DECmcc T1.2.7.

$ mana/e

DECmcc (T1.2.7)


MCC> show node4 panpan obj mcc_evc_sink all attr


Node4 51.931 Object mcc_evc_sink 

AT  2-JUN-1992 16:56:47 All Attributes


                                   Name = 
MCC_EVC_SINK


                                 Number = 
0


                             Process ID = 
%X000001A7


                           Initial Name = 
MCC_EVC_SINK


                         Initial Number = 
0

MCC> disable mcc 0 coll sink decnet


MCC 0 COLLECTION_AM SINK DECnet 

AT  2-JUN-1992 16:57:21 


Disable completed successfully.


MCC> enable mcc 0 coll sink decnet


MCC 0 COLLECTION_AM SINK DECnet 

AT  2-JUN-1992 16:57:47 


Enable completed successfully.


MCC> show collector *

Using default ALL IDENTIFIERS


Collector LOCAL_NS:.mycollector 

AT  2-JUN-1992 16:58:42 Identifiers


Examination of attributes shows



MCC> 

MCC> notify domain demo entity list = (collector mycollector) , event=(any event)

%MCC-S-NOTIFSTART, Notify request 1 started

BTW: When I tried to do this from the iconic map through notification services
'create' and filled in the fields: 
domain:demo
entity list : mycollector
events:any event

I got a error window on the second field, stating:
'error while creating notification command' %MCC_W_INV_ARG, invalid argument.

Than, when done through FCL it seemed to have worked.

$ mcc_evc_send :== $sys$common:[syshlp.examples.mcc]mcc_evc_send

I had setup the proxy as stated in previous notes.

$ mcr authorize
)0
=

UAF> show/proxy *

 Default proxies are flagged with (D)

PANPAN::NSDP
     NSDP (D)

I am working on PAN on account NSDP


UAF> exi
%UAF-I-NOMODS, no modifications made to system authorization file
%UAF-I-NAFNOMODS, no modifications made to network proxy data base
%UAF-I-RDBNOMODS, no modifications made to rights data base
>
$ mcc_evc_send PANPAN "mycollector" "" "title" "text" "CRITICAL"

I have at this moment a IMPM window open in the domain with the collector
and the node PANPAN and also the notification services window. 
The command is accepted, but nothing happens. 

I also have another system in this domain called GIBBY.

$ mcc_evc_send GIBBY "mycollector" "" "title" "text" "CRITICAL"
%SYSTEM-F-INVLOGIN, login information invalid at remote node

Isn't gibby just the destination on the map? Why do I get this message? and
why doesn't the first command result in a notificationa nd a color change on the
map.

Thanks

Timo

After some more twiddling around and rereading the manual, I got it partially
working , but still have some questions. I found out that when entering as
entity : COLLECTOR mycollector in the 'create notify event' window, the 
command :

$ mcc_evc_send PANPAN "mycollector" "" "test" "this is text" "WARNING"

indeed results in a warning message in the notification window, BUT the 
collector icon changes color instead of the PANPAN icon (which I expected)

$ mcc_evc_send GIBBY "mycollector" "" "test" "this is text" "WARNING"

still gives:

%SYSTEM-F-INVLOGIN, login information invalid at remote node

$ mcc_evc_send PANPAN "mycollector" "GIBBY" "test" "this is text" "critical"

Also results in a notification but no color change of PANPAN or GIBBY.

Could someone explain what the exact meaning is of the 'destination' and 'target'
fields.

Thanks

Timo

After having set a notify request also on node4 PANPAN ANY EVENT and rexecuting

$ mcc_evc_send PANPAN "mycollector" "PANPAN" "test" "this is text" "critical"

I get the notification for the collector entity which changes color to 'critical'
and than ,after a while, I get the notification:

MCC> notify domain demo entity list = (node4 panpan), event=(any event)
%MCC-S-NOTIFSTART, Notify request 1 started
MCC>

%%%%%%%%%%%%%% Event,  2-JUN-1992 18:08:22 %%%%%%%%%%%%%% [1]
Domain: LOCAL_NS:.demo                                Severity: Indeterminate
Notification Entity: Node4 LOCAL_NS:.panpan Circuit SVA-0
Event Source: Node4 LOCAL_NS:.panpan Circuit SVA-0
Successfully received events:
Event: Aborted Service Request
 Aborted Service request
                                 Reason = line open error
                Target Ethernet Address = 08-00-2B-09-15-40

which is repeated every minute. Why do I get this aborted service request,
and why is it repeated every minute? I also tried retargeting to NODE4 GIBBY,
but no notification...

any help appreciated

Timo

When you do this:

 >MCC> notify domain demo entity list = (node4 panpan), event=(any event)
 >%MCC-S-NOTIFSTART, Notify request 1 started
 >MCC>

You are requesting *any* events defined for class NODE4, instance PANPAN. 
(i.e. DECnet events.)    After you do this, you should start to see DECnet
events on your MCC system (which you *did*).  The aborted service request event
that you're seeing is a DECnet event and has absolutely NOTHING to do with the
Data Collector.  If you terminate Notify Request 1, then you should cease
seeing those events.
 
Are you trying to get the icon for NODE4 PANPAN to change color using Data
Collector events?   If so, then you need to fully specify the target entity to
the mcc_evc_send.exe program like so:

$ mcc_evc_send -
	PANPAN 
	mycollector -
	"NODE4 PANPAN" -
	test -
	"this is text" -
	critical 

Note that the text doesn't need to be in quotes UNLESS it contains embedded
spaces (e.g. "NODE4 PANPAN")

Please read the comments in the example file mcc_examples:mcc_evc_send.c for
more detailed discussion of the arguments to the mcc_evc_send.exe

/doug

the purpose of the mcc_evc_send.exe program is to send a data collector event
to the DESTINATION system.  The DESTINATION system is assumed to be either a
VMS or ULTRIX system running DECmcc V1.2 *and* the data Collector event sink.

If the DESTINATION is not running the Data COllector event sink, then you will
receive the 		
	%SYSTEM-F-INVLOGIN, login information invalid at remote node
message.

The TARGET is any alternative FULLY SPECIFIED entity in a DECmcc domain that
you would like to have the notification 're-vectored' to (on the IMPM).  Fully
specified means that both class and instance are specified in the string. E.g.
"NODE4 MCDOUG" , "Bridge .TOOFAR" etc.  Just an object name (i.e. "MCDOUG")
will not cut it.

IF you want NODE4 GIBBY to change color instead of collector mycollector, then
fully specify "NODE4 GIBBY" in the "Target" parameter.

/doug

    
                                             
    Hi,
    
    	If you don't specify the third argument (e.g. target entity) when 
    	using mcc_evc_send (in your first example, ""), collector entity 
    	(in this case, mycollector) should change color.
    
    	If you wish to have the target entity change color instead of
    	Collector entity, you must FULLY specify the target entity in the
    	third argument when calling mcc_evc_send.  For example, specifying 
    	"node4 PANAN" or "reference printer" will enable these icons color
    	to be changed when the message arrives. In your note .10, you did 
    	not specify "node4" entity class when calling mcc_evc_send.
    
    	"Destination" merely specifies where you would like to send the 
    	collector text message to.  It is where your MCC station resides.  
    
    	"Target entity" specifies the entity that is associated with
    	the requested events, and whose icon is what you would like to change
    	color on.  
    
    	Hope this helps.
    
    	Jean
    
    
    	
    
    

Thanks. This makes things already much clearer. Maybe the documentation could 
be updated/modified with:
1. The example on page 8-17 is not correct since it doesn't name the 
   global entity COLLECTOR.
2. Make clear that the third parameter should be specified as
   "GLOBAL_ENTITY_CLASS GLOBAL_ENTITY_INSTANCE" (and therefore always 
   quoted since it will always be two words ,won't it?)
3. The NOTIFY command on page 8-16 is missing a comma before EVENT.

If I understand it well, the print queue example in the manual assumes that,
DECmcc,the commandfile,mcc_evc_send and the sink are all running on system 
ROME. So if I want to use this commandfile for another system, I would
copy the commandfile and mcc_evc_send.exe to the other system (let's say
LONDON) and than edit the commandfile on LONDON, so that the mcc_evc_send
command would be:

$mcc_evc_send ROME "print queue" "NODE4 LONDON" "stopped" "text" "critical"

This would than cause a message to be send from LONDON to ROME (the DECmcc
system) and the icon LONDON would change color. Is that right?

Thanks

Timo

We new there were problems in the notification services book, where the
collection AM is documented, but couldn't hold up the product for just
that.  So we weill be rereleaseing the notification book with many 
enhancements (especially to examples and appendices) when the EMS
kit is released, so you will want to get a new copy when it becomes
available.

thanks for the input.