| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1365.1 | | BSYBEE::EGOLF | John C. Egolf LKG2-2/T02 x226-7874 | Wed Aug 21 1991 08:54 | 9 |
| re .-1
For alarms that get triggered, its easy. We supply a dcl
command file that writes the information (including timestamp)
to a log file of your choice.
For events that come in and don't trigger an alarm, that
function doesn't currently exist although we discussed using
the Historian to record events.
|
| 1365.2 | SNIFFER model worth considering | ENUF::GASSMAN | | Thu Aug 22 1991 16:54 | 9 |
| Having just spent a few days on a SNIFFER, I found their model of
capture and display useful, and may be something to consider in the
design of a future MCC funtion. The capture buffer will grab 'events'
that meet filter criteria, based on quite a few different type of
attributes. THEN, the display function can either display and analyze
all captured events, or a second filter can be placed on the captured
data so only the events of your interest are shown.
bill
|
| 1365.3 | to file on the notify command works | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Tue Aug 27 1991 16:08 | 13 |
|
not real "nice" but it does work....
you can set up the fcl running through a set host/log and
then start the notify commands running. This will produce a log
for any entity you ask it to pick up events on.
the other option is to use the TO FILE qualifier and put that
on the end of the notify command, this will automatically pipe
the events to the file specified.
jill
|
| 1365.4 | Will TO FILE capture evry thing ? | CLARID::PATEL | We'll get it right on the night | Wed Aug 28 1991 06:41 | 4 |
| Will the TO FILE, pass all events that came in to the file or just the
ones for which a rule fired ?
Amrit
|
| 1365.5 | to file based on command | TOOK::CALLANDER | Jill Callander DTN 226-5316 | Wed Sep 04 1991 10:56 | 19 |
| The notify command from the fcl is significantly more powerful than the
functions we made available from the map.
The notify command allows the user to request rule events, as well
as events ony other entity class that supports them. The command (NOTIFY)
and it's arguments are discussed in the BMS Use manual.
If you enter a command like:
NOTIFY DOMAIN foo, to file foo.events
This will only put rule events (rule fired, and rule exception) into the
file foo.events.
If you enter a command like:
NOTIFY DOMAIN foo rules=(*), events=(any events), entity list=(node4 *)
You will get the rule events (fired and exception, as well as any event
generated on the node4 global entities in domain foo. To find out the list
of entities in domain foo, you can do a show domain foo memeber * all ident
and you will see the members of the domain.
|
| 1365.6 | thanks | CLARID::PATEL | We'll get it right on the night | Wed Sep 04 1991 14:12 | 3 |
| Things are looking more promising ... :-)
Thanks
|
| 1365.7 | v1.2 notif | GOSTE::CALLANDER | | Sat Sep 07 1991 10:51 | 3 |
| if you think what you have in v1.1 is "more promising" just wait
til you see what you get in v1.2!
|
| 1365.8 | audit trail of all configuration changes | HGOVC::LILLIANTANG | | Mon Sep 23 1991 23:51 | 6 |
| How about recording all activities related to configuration changes?
Currently events are limited to only a few entity class and may not
include all changes made. A customer we encounter wants an audit
trail of all changes (e.g. enabling/disabling a bridge line) to all
entities. Any suggestions? thanks, Lillian
|