[widar-wg] Alerts - CM - configuration failure

Bill Sahr bsahr at nrao.edu
Fri Jun 3 15:06:39 EDT 2011


Pls see below.

Sonja Vrcic wrote:
> Michael,
> thanks for the quick response, please see my comments below.
> Sonja
> 
> 
> Michael Rupen wrote:

> 
> My understanding is that operator can see only one alert of the same 
> type on the screen. If that is true, and CM implements a) operator would 
> see only the last generated alert (config ID). Therefore b) seems to be 
> a better solution.
> 
> Config ID could be added to the alert message as a parameter. Since 
> alert can have multiple parameters, CM could add two or more config IDs 
> to the same alert.
> But, is it possible to display one or more config IDs on the operator 
> screen.
> And, if specified as parameter(s), would config ID(s) be added to the 
> archive.
> 
If specified as a parameter, I don't think config IDs would be archived.
To be archived, I think one would have to specify the config ID as an
attribute of the "archive" element, perhaps as "mon".

There is another option not yet discussed - there is a variant form of
monitor data being used for the vlba that describes the monitor point
data table as:

> hostname varchar(20) not null,
> devicename varchar(20) not null,
> monpointname varchar(30) not null,
> timestamp double precision not null,
> status int2 not null,
> monpointvalue double precision not null,
> monpointstr  varchar(20),
> dtype  int2  not null

monpointstr & dtype are the variant fields.  If these fields were included
as attributes in the archive element & in the alertdata table in the
database, then config ID could be set as the value of monpointstr.
Of course, adding these fields to the archive element would mean modifying
the xAlerts schema.

Bill




More information about the widar-wg mailing list