Re: Help with bumpless IOC reboot, record linking and initialization concepts

[Timo Korhonen via Tech-talk <tech-talk at aps.anl.gov>]

Hi Maren,

I guess there are use cases where dbpf is a good solution. However, we have tried to root out dbpf's from startup scripts. Main reasons:

-dbpf does not play well with autosave. If the PVs were changed by operators, and the IOC restarts, the autosaved values will be overwritten, and you get a nice surprise __
-putting system configuration in dbpf's scatters the configuration parameters in places which are hard to track and find - unless you are very familiar with the whole system.

The main reason why people have used dbpf has been to overload default values from community templates. 
There is a clear and understandable need for this; we do not want to fork and diverge from the upstream.

However, as a better (IMO) alternative, we use overloading of the records, as described here: https://urldefense.us/v3/__https://docs.epics-controls.org/en/latest/appdevguide/databaseDefinition.html*definitions-8__;Iw!!G_uCfscf7eWS!c5Iul-6qd9gvOLS8bKautlTg46ra1LRyWLkP83MkR8OF8t9quvtdonZ8I9Vg1VJ4d3dqt4-deHfcrw6254K-XaaJo1vR$ 
(I see some need for documentation improvement here...not the most obvious place to look for this feature).

Best regards,

Timo

On 2025-09-19, 05:32, "Tech-talk on behalf of Maren Purves via Tech-talk" <tech-talk-bounces at aps.anl.gov <mailto:tech-talk-bounces at aps.anl.gov> on behalf of tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:


We often use dbpf for temporary changes of alarm thresholds for
instrument temperatures and pressures.
The db contains what they should be if everything was working properly.
I don't see how that is bad coding.


Maren


On Thu, Sep 18, 2025 at 7:10 AM Michael Davidsaver via Tech-talk
<tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:
>
> On 9/18/25 07:54, Johnson, Andrew N. via Tech-talk wrote:
>
> Many of our IOCs use one or more “dbpf” commands in their startup script (sometimes after an epicsThreadSleep) ...
>
> Nooooooo!
>
> Finding a bunch of random, rarely commented, dbpf calls in an IOC start script is to me a bad code smell. The same goes for sleeps, only more so. Please investigate 'field(PINI, "RUNNING")', or look at other ways to actually synchronize startup.
>
>
> ... it should even be possible to handle disconnections and later reconnections for links to remote IOCs if you want to do that.
>
> imo. any well written driver for an ethernet attached device __needs__ to do this.
>
> Generally, I have found that the more effective way to coordinate connect/disconnect is at the driver level. Generally with a special device support to drive on-connect processing.
>
>