Title: | DECmcc user notes file. Does not replace IPMT. |
Notice: | Use IPMT for problems. Newsletter location in note 6187 |
Moderator: | TAEC::BEROUD |
Created: | Mon Aug 21 1989 |
Last Modified: | Wed Jun 04 1997 |
Last Successful Update: | Fri Jun 06 1997 |
Number of topics: | 6497 |
Total number of notes: | 27359 |
Hello, We're using a specific alarm notification procedure in our alarm rules because we have to display specific entity information in addition to the DECmcc alarm information. The type of the alarm rules is event detection (OCCURS) format. - Sometimes, the alarms rules fire (shown by the icon changing colour), but we can see both of them not working: o We do not see any alarm broadcast ! o It appears that alarms are not being broadcasted in the same order as it's done by the 'Event Put' routine encoding. - And some alarms seem to get lost completely when there are too many to fire off. Is there a limited number of alarms ? Are they known problems in V1.1 ? Best Regards, Thierry.
T.R | Title | User | Personal Name | Date | Lines |
---|---|---|---|---|---|
1703.1 | Does this help? | TOOK::ORENSTEIN | Thu Oct 24 1991 14:15 | 11 | |
I don't know of any explicit problems with ALARMS notification in the V1.1 product. But here are some things to consider. When ALARM notification is done, a job is submitted to your batch queue. If you have a large number of rules firing, it is quite likely that you will see a delay between visual notification (clour change) and the ALARM notification. I do not know what happens when your queue is full and another job is submitted -- could it get lost? aud... | |||||
1703.2 | multi threads means random order of activation | TOOK::CALLANDER | MCC = My Constant Companion | Thu Nov 21 1991 13:16 | 5 |
Also note that MCC is multi threaded. This means that multiple rules mean multiple processing "threads". These threads are scheduled on a first "ready" first activated basis. This doesn't necessarily mean that the first on activated is for the first event put... |