Re: More flexible record scanning

[Benjamin Franksen <benjamin.franksen@bessy.de>]

On Monday 27 June 2005 16:33, Andrew Johnson wrote:
> Benjamin Franksen wrote:
> > Only for record (sic!), because I just had a problem where this
> > would have been quite useful: In R4, each record (i.e. dbCommon)
> > should have an input link targeting the PROC field.
> >
> > Standard application: a potentially large number of records needs
> > to be scanned according to what happens at some central place.
>
> Can that requirement not be implemented already in V3 using this?
>
>      SCAN=Event
>      EVNT=<some number>
>      Use an Event record to generate that numbered soft event.
>
> If the records to be processed are spread across multiple IOCs, you
> need to have one Event record in each IOC.

I got a similar answer from Marty. To re-iterate my response:

Event scanning using raw numbers is much too fragile. It means you 
cannot load two independently developed databases on the same IOC 
without incurring the risk that both happen to use the same event 
number(s) for entirely different purposes. Such an error would not 
become apparent when loading the databases, but only later during 
runtime, possibly a lot later if the events in question occur rarely. 
Thus, the error may be quite subtle and cost you a lot of time to 
debug.

Note that the two databases may work absolutely correct when used 
separately, i.e each loaded on a dedicated IOC (a setup you would 
typically use during development).

In contrast, an input link for the PROC field never accidentally 'leaks' 
to the outside, at least if the 'scanning' record instance is part of 
the same database file.

Ben