Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Tue, 20 Jun 2006 10:05:43 -0500

Hi Bob,

Bob Dalesio wrote:

> It would be nice if there was one place to plug in all new things 
> that were interested in monitors.

The requirements for a hook for monitor events are rather different to those for just alarm changes, which is what DESY and FNAL are looking for here. The recGblResetAlarms() routine where this hook resides actually calls db_post_event() several times (for the record's STAT, SEVR and ACKS fields) as well as calling the new hook routine, so I suspect you won't need to use this hook at all for redundancy purposes (in fact in using a simple function pointer for the hook I assumed that you wouldn't).

> We have one for redundancy. You would like one to handle alarms 
> differently. I expect that one could use this to make a ca client 
> that filters on event and triggers. It could also be used for a  
> logging facility. The real point of all of this, is that we need to 
> be able to have connection-less clients. These are clients that do 
> not want to make tcp/ip connections to each channel - but have 
> changes pushed out to them.

The hook for db_post_event() is going to be a bit more complicated, and what I'd like to do is make that into a proper registration interface.  We have two different subsystems that both want to see db_post_event() calls: the CA server (currently RSRV), and your redundancy subsystem, and it would seem sensible for both of these to use the same method to hook into the database code in order to get called from db_post_event().  In the case of the recGblAlarmHook I couldn't see an immediate need for calling more than one hook routine in any particular IOC which is why I went with the simple function pointer (although this approach can be used for multiple routines - each one must save the previous pointer value when it inserts itself and call it from its own hook routine).

> I assume that intial record processing causes all fields that are 
> changed to call dbPostEvents. Any clients listening would see each 
> new record that just came online.

If a field never changes, nothing will call db_post_event() for it.  For example, until a record goes into alarm there will be no db_post_event() calls for the STAT and SEVR fields.  This is equally true at initialization time, meaning that the first call to db_post_event() will probably be from the first I/O operation that causes a field value to be modified.

> Can this hook be put into one place?
> Is it a problem if the alarm hook has to check the alarm_flag to 
> see if it is a change of alarm? It is an extra call to the alarm 
> hook for many things that did not change alarm state - but it would 
> be one hook into record processing that monitors changes.

We need different hooks for different purposes; I have no problem with putting multiple hooks into the database code.  The recGblAlarmHook provides a way for its plugin to see what the alarm status and severity changes were for a particular record.  Your requirements are very different, and I'd like to work with you and Jeff Hill to see if we can design this so as to provide a clean interface up to the server.  If we do this right, it could become a way to plug other transport layers on top of the IOC database in parallel with CAS.

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System