AlarmServerApp

Introduction

AlarmServerApp is a persistent server that allows its client's to access a database of experiment related alarms.  Clients connect to the server on a tclserver and request that the AlarmServerApp process their requests.  Some features of AlarmServerApp include:

• Persistent server means that if the server dies because of one client, it will be restarted automatically and other clients wont be stranded.

• Allows multiple clients access to a single database of alarms, while ensuring that no other application reads from or writes to the database file.  This prevents read/write conflicts between experiments and their alarm displayers.

Usage:

AlarmServerApp is located in /opt/daq/bin in the Linux data acquisition system.  If this directory is in the path, simply type the command:

    AlarmServerApp

When the server is running properly, the following message will be displayed:

    Listening for connection requests...

AlarmServerApp will be running on the current host, listening on the port specified by daqalarm in /etc/services, or port number 2702 by default if /etc/services is not configured for daqalarm.  Now the AlarmDisplay script can be started with the host and port number specified as the host and port of the AlarmServerApp (u3pc3 and 2702 by default).

The server should be invoked from the same directory each time it is used.  Upon instantiation, it creates two new files in the current working directory called ".alarmdb" and ".alarmcount".  The first file is used to store alarm information, including the unique alarm id number, the name of the logging facility, the current alarm status, the message associated with the alarm, and the date and time of the alarm occurrence.  The second file is used to store the number of alarms logged to each experiment in the database file, so that a unique id can be assigned to each incoming alarm based on the id of the previously logged alarm.  Both files are needed for the server to run, and they should not be deleted while the server is running.  Making them hidden files reduces this risk.

Functionality:

Once the server is up and running, it can receive messages from CAlarmLogger objects which use the CSocket class to form network connections.  The server provides the following functions:

• Log -- Adds an alarm entry to the alarm database in ".alarmdb", and increments the experiment alarm count in ".alarmcount".

• Acknowledge -- Changes the status of the alarm specified from New to Acknowleged in .alarmdb.

• Dismiss -- Changes the status of the alarm specified from Acknowledged to Dismissed in .alarmdb.

• Update -- Returns all of the information contained in .alarmdb for the given experiment.

• Init -- Returns the number of alarms for the specified experiment.

• Create -- Creates an entry for the specified experiment in .alarmcount.

• History -- Returns all of the information contained in .alarmdb for the given experiment as a string suitable for displaying.

May 20, 2002 venemaja@msu.edu