Maren writes:
...we would like to notify a group of people by email.
Is there a way to set up the alarm handler to do this?
.
.
.
This looks like a starting point for a new wishlist for alh features.
In the past I already discussed some new features with Janet which I want to publish here
and ask for response:
My proposal (>) - Janets response
>Avoiding multiple writes to log-files
>-------------------------------------
> Another question around writing alarm messages to a file:
> We want to run the alarm handler multiple times with the same config file and
> the same log files. This would mean that any operator action will be written
> to the same file. On the other hand each alh will write the same log messages
> to the alarm-log file. Only by setting the _L_ flag for each record will disable
> writing the same alarm to the common log file.
> What is the idea:
> - to set a flag during alh startup (like -r) to make the alarm log file
> read-only regardless whats written to the individual record.
You are correct, multiple alarm handlers writing to the same file will not be
handled properly, We have some of our operators run alh from a command line
something like the following so that each copy of alh has its own output files.
alh -a alarmlogfilename.`echo $DISPLAY` -o opmodlogfilename.`echo $DISPLAY`
I like your idea about a command line flag to enable/disable logging. The next
time I have modify alh I will see if I can add this feature.
>Automatic file creation with my_alarm_log.dd-mmm-yyyy extension
>---------------------------------------------------------------
> In addition we would like to keep all alarm messages. To avoid endless log files
> you already implemented the maximum file size. Could you also think of a way
> to specify alarm log files like my_alarm_log.dd-mmm-yyyy
> YYYY year
> MMM month
> DD day
> The maximum size for a log file would also apply here for the individual file.
> In addition this would imply that the alh would need a file-select box to
> select the current alarm file or a file from another day.
>
> Writing messages to the file will automatically switch to a new filename at
> midnight.
>
> We already use this method for another application (non-EPICS) and in fact
> find it very useful.
> In addition we have a batch job which starts on the 1st each month and
> searches through the individual alarm files and gathers the most important
> alarm messages in a monthly summary file. This file could also contain summary
> informations from another alh log (from another control area). You see:
> extensions are possible (as always)...
Yes, I have thought about renaming the specified log files ( alarm log and
operator modificaton log files) by appending the time (using the c function
time(NULL)) to the filenames if they exist each time the alarm handler starts
up and then create new log files with the specified names at alh startup.
However, operations here is not interested in keeping a history of alarm
messages, so I implemented the circular file for them instead. It was decided
a long ago, before I took over the alarm handler code, that alh would not be
used for logging and keeping message archive history files but rather alh is
to be used to bring current alarms to the operator's attention and assist the
operators in handling current alarms. We use other tools here to log alarms
and other events. Yes, maybe better alarm log handling by alh should be discussed
on tech-talk or at an epics meeting. Others may also want the file handling
method that you have suggested. Why don't you give your suggestion and ask
for feedback. I would be very willing to change the code.
>New Parameter for the config file
>=================================
>Send Mail
>---------
$MAIL [email protected] "Message to be sent" (add actual value with current alarm limits
automatically)
>Specify HTML reference
>$HTML http://www-server.web.node/info-page.html
>If specified it will need another button in the Alarm Handler Window to jump to that html
reference. This will imply that a web browser will be started (if not already running) and
the specified web-page will show up. Such behaviour is currently implemented for the
medm-help support (UNIX script) By Vladimir Romanowsky.
>Send value to specified record once the alarm of the supervised record is acknowledged.
>$ACKREC record-name value
>Background:
If alarms are checked by a frontend system (i.e. a PLC) and by the alarm handler both
systems will show an alarm. Once the alarm is reset in alh the alarm in the frontend will
still show up. A reset send to the frontend would also reset the local alarm state.
Matthias
Matthias Clausen Deutsches Elektronen Synchrotron
DESY
Gruppe: MKS2/KRYK
Notkestrasse 85
D-22607 Hamburg Bahrenfeld
Tel: -49 40 8998-3256 [email protected]
Fax: -49 40 8998-4388 [email protected]
- Navigate by Date:
- Prev:
Alarm handler question Maren Purves
- Next:
Re: ALH Wishlist Mark S. Engbretson
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Alarm handler question Maren Purves
- Next:
Re: ALH Wishlist Mark S. Engbretson
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|