| T.R | Title | User | Personal Name
 | Date | Lines | 
|---|
| 4679.1 | trivial. | TOOK::MCPHERSON | pre-retinal integration | Thu Mar 11 1993 22:23 | 10 | 
|  | 
    Piece of cake.  I hacked this sort of thing together for the MCC demo
    at InterOp 90.  [Let me tell you, it got pretty tiresome hearing the
    demo station yak on about how the "... Proteon router has seen > 100
    ifInErrs"]
    You just need to modify one of the sample alarm procedures on the kit
    to open the DECtalk TT port  & write out the appropriate messages.
    /doug
 | 
| 4679.2 | What about DECsound | MQOSWS::F_MONETTE | Montreal Sales Support | Fri Mar 12 1993 08:45 | 7 | 
|  | You can also use DECsound if you want to. Since DEcsound 
comes with Motif 1.1 and any new VAXstations, it very
easy to do and you may want record your own voice.
Regards,
Fran�ois
 | 
| 4679.3 | thanks, how abount using the collection module | OSAP02::MERMEL |  | Fri Mar 12 1993 10:36 | 16 | 
|  |     Thanks,
    
    Just one more question,
    
    I do not see a way for the collection module.  The examples (and what
    I have tested) do not use an alarm module.  Can I create one for the
    collection module.  I am told that you can use a command procedure from
    the collection module, but I can't find it.
    
    Thanks
    	Adam
    
    ps,  if anyone has an example of this already done, would they either
    please post it here, or send me mail at osap02::mermel
    
    
 | 
| 4679.4 | Basic Principles of Rules... | TOOK::R_SPENCE | Nets don't fail me now... | Fri Mar 12 1993 12:49 | 15 | 
|  |     I think there is a missing piece of info here....
    
    A couple of basic principles may help;
    	Alarm rules can run a DCL (or shell on Ultrix) script when they
    		fire or
    		encounter an exception
    	When rules fire or encounter an exception they generate an event
    	The Data Collector actually collects events
    	Events can come from DECnet event sink or TCP/IP trap sink
    	Alarm rules can be written for events
    
    So, to use Data Collector events, write a rule that checks for it,
    have it run a script, have the script talk to DECtalk etc.
    
    s/rob
 | 
| 4679.5 | Possible sticky wicket here... | MCDOUG::doug | pre-retinal integration | Fri Mar 12 1993 13:01 | 9 | 
|  | >    So, to use Data Collector events, write a rule that checks for it,
>    have it run a script, have the script talk to DECtalk etc.
The downside to this is that the only event type returned by the Data Collector
is that of "General Event".   OCCURS alarm rules are created on event type,
so this means that ANY Data Collector event will cause the rule to fire.  I
repeat: ANY Data Collector Event will cause the rule to fire.  
/doug
 | 
| 4679.6 | seperate by directory | CTHQ::WOODCOCK |  | Fri Mar 12 1993 19:43 | 16 | 
|  | 
>> I repeat: ANY Data Collector Event will cause the rule to fire.  
You can use directories for partitioning these objects. Place all data 
collectors in a specific sub-tree of the MIR/DNS. Say .COLLECTOR for example.
Then you can write a rule expression like:
exp=(occurs(collector .COLLECTOR.* any event))
This works in V1.2 so you could seperate your collectors for specific uses.
Not tried for V1.3 and I don't even know if it's supported.
best regards,
brad...
 | 
| 4679.7 | Luck trumps Skill... | TOOK::MCPHERSON | pre-retinal integration | Sun Mar 14 1993 13:26 | 7 | 
|  | Brad, 
That capability is entirely accidental (a fluke of the Notification FM).  We're
lucky it worked at all, but I'm glad you've been resourceful enough to
document the workaround...
/doug
 |