Re: IOC, QServ, and AMSG / alarm.message

[Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>]

On 2/18/25 04:29, Ivan Finch - STFC UKRI wrote:

> It appears that this is not the intended behaviour of the AMSG field?
To take the last question first.  No, not really.  (at least if I understand
you correctly)

The intent of AMSG is as context to help differentiate the different causes
of an alarm for a single record.

As a motivating example, PVXS PR #100 which I asked Aqeel to test adds a line:

>            (void)recGblSetSevrMsg(plink->precord, LINK_ALARM, INVALID_ALARM, "%s Disconn",
>                                   dbLinkFieldName(plink));
Here a PVA link signaling an INVALID/LINK alarm this will set AMSG to
eg. "INPA Disconn" for a calc record, where it can otherwise be difficult to
know which of several INP* fields in causing an alarm condition.

Now we have to get into more philosophical "theory of alarms" territory.

I was once in a discussion with an Operations group with strong opinions about
what an Alarm was.  They had their reasoning, which I mostly agreed with.  But we
could not agree to redesign the EPICS alarm model, and instead ended up with an
understanding that EPICS alarms are actually "engineering notifications".  A lower
level input into an alarm management system.

So my short, perhaps less helpful, answer is that the sort of high level meaning
which I think you are after is best expressed in a high level alarm service.

It sounds like your "bridging software" is a start along the road which has led
others to creating services like [1].

[1] https://urldefense.us/v3/__https://accelconf.web.cern.ch/icalepcs2009/papers/tua001.pdf__;!!G_uCfscf7eWS!d1ZF2uqRBKYTpTShk0LaepY-uU7XJJHkt6eDCO9zxr-P9sPvma4QFmrdC93PBXsV4DyC8FvS3z849W6JG3mz38V4Jw$