Re: When must recGblResetAlarms be called?

[Marty Kraimer <mrk@aps.anl.gov>]

J. Frederick Bartlett wrote:
>   I have a question concerning the use of the function recGblResetAlarms in
> conjunction with the db_post_events function.
>
>   I wish to raise a monitor event when selected fields of a record are
> changed by a dbPutField call (usually via a channel access message).  The
> fields are all marked for special processing -- the special(SPC_MOD)
> attribute of the field has been set. The examples indicate that monitor
> activation during the "process" phase clearly require an initial call to
> recGblResetAlarms; however, when the change of value takes place outside of
> a call to the record's process function, does recGblResetAlarms need to be
> invoked?
>
> 									Fritz

In most cases recGblResetAlarms should NOT be called.

Let's review what recGblResetAlarms does (It also sets alarm mask but that is 
not important for this discussion).

It sets

stat = nsta    set status equal to new status
sevr = nsev    set severity equal to new severity
nsta = 0       set new status to 0
nsev = 0       set new severity to 0

What is assummed is that no more alarms will be raised from the time 
recGblResetAlarms is called until db_post_event is called for any field that the 
 record support process method monitors. recGblSetSevr changes the nsta and 
nsev fields NOT the stat and sevr fields. If something not connected with 
processing calls recGblResetAlarms then alarms connected with record processing 
may be lost.

Fritz's question relates to issuing a db_post_event to a field that is not 
monitored by the record support module. The status and severity that will be 
associated with the db_post_event will be the status and severity related to the 
last time recGblResetAlarms was called, i.e. the last time the record was processed.

In most cases this should be OK. If the db_post_event is for a field not 
monitored when the record is processed alarms should not be of interest. For 
example consider the aiRecord. It has a special routine that looks for field 
LINR being changed. If it detects a change it also checks to see if ESLO and 
EOFF change and if they change it calls db_post_event. If a CA client monitors 
these fields asking for severity and status it will get the status and severity 
from the last time the record was processed. Thus it could get the old status 
and severity even though they have changed because the record  has started but 
not completed processing. I will maintain that the CA client should not be 
asking for status and severity for such fields. If it does it will also receive 
an event each time the status and severity change.

If a record support module has a lot more "state" than normal records perhaps 
there might be a reason for code other than process to call recGblResetAlarms. 
But think hard before creating such record support.

Marty Kraimer