| Huh?
Mic, mcc_evc_send.exe is a standalone program run from the system command
interpreter (i.e. DCL on VMS, csh or whatever on U*X) and NOT from within MCC
FCL as your example infers: MANAGE/ENTER MCC_EVC_SEND "que_stopped" "error"
"hi" "warning" "decnet"
This is the order of the arguments that the mcc_evc_send.exe program is looking
for:
$ mcc_evc_send <mcc_node> <collector_name> <target_entity> <event_title> -
_$ <event_text> <severity> <protocol>
example:
$ mcc_evc_send mcdoug que_stopped " " Error Hi warning Decnet
^ ^ ^ ^ ^ ^ ^
| | | | | | |
MCC | Target | | Severity |
System | | | |
Collector Event | Protocol
Name Title |
|
Event
Text
Note that quotes aren't needed unless you're passing in a null string or
a string with embedded spaces.
If I had wanted the icon for node4 BOEHM to light up because the queue on
BOEHM had stopped, I would have targetted the data collector event to that by
simply specifying "NODE4 BOEHM" in the <target_entity> argument to
mcc_evc_send.exe instead of just passing in a null string, like I did in the
first example.
Example:
$ mcc_evc_send mcdoug que_stopped "node4 boehm" Error Hi warning Decnet
> In using the MCC_EVC_SEND.EXE program I ran into something weird...
> I used almost the identical program in the COLLECTOR doc, to prove to a
> customer that the COLLECTOR could NOTIFY & TARGET and eventually ALARM.
It may be that the docs are screwed up on this -- I don't know (I haven't read
the 1.3 docs...). If you look over the comments in the source code
mcc_evc_send.c (on the kit, somewhere in the mcc directories) you'll get a
better explanation of how the application is supposed to work.
> Well, I setup the SINK, setup the COLLECTOR, and fired off the
> MCC_EVC_SEND, first from FCL and then the IMPM; the severities are
> DIFFERENT!
Like I said, you can't 'fire off the MCC_EVC_SEND' directly from within MCC --
you do it from the system prompt. mcc_evc_send.exe is a standalone
application from MCC. If you want to send a data collector message from
within MCC, you need to use the "Send Message" directive.
To sum up: the behavior you are describing is not consistent with any bugs I
know of, except for possibly bugs in documentation. I've told you about all I
can.. Keep trying.
/doug
|
|
Reply to .0
Aside from Doug's correction to the command, you also need to check how
your notification is instructed. Please pull down "options" from your
map, click "map...". Check your "propogation" selection. If your
selection is "highest", then your notification will only show the
highest severity of color (in this case, RED). But if you select
"latest", then the color will change according to the severity level of
the event you send.
Check it out, and let me know how it goes.
Jean
|
|
> Aside from Doug's correction to the command, you also need to check how
> your notification is instructed. Please pull down "options" from your
> map, click "map...". Check your "propogation" selection. If your
> selection is "highest", then your notification will only show the
> highest severity of color (in this case, RED). But if you select
> "latest", then the color will change according to the severity level of
> the event you send.
There is also another solution to correlation. Be careful with LATEST because
it can cover up problems in the domain hierarchy but it may be good for you.
What we do to get COLLECTOR event correlation is to send the ***EXACT*** text
in the EVENT TITLE field with different severities. Your que example would
then be:
$ send_event <collector> "node4 x" "Queue Status Change" "Down" "critical" decnet
$ send_event <collector> "node4 x" "Queue Status Change" "Up" "clear" decnet
The clear event will override the critical in this example even using HIGHEST.
Good stuff cheap...
cheers,
brad...
|