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

[Maren Purves via Tech-talk <tech-talk at aps.anl.gov>]

Thanks Timo,

yes, I can see that leading to problems - but we're not using it.
We mostly have buttons to control things, which of course have
predefined values.The only thing where operators (users) sometimes
input  values are numbers (like the frequency or position of
something) and those won't get saved because they're usually
irrelevant the next time. All our setups are in ASCII or xml files
that get read in or the values submitted by other software - and have
one or two people dedicated to maintaining those (among lots of other
stuff they also do).
The dbpf-s we do use usually only happen when e.g. an instrument
temperature is a few degrees (or a few tenths) above where the alarm
handler(s) would kick in, i.e. usually only HIGH, LOW, HIHI and LOLO
fields.

Aloha,
Maren

On Sun, Sep 21, 2025 at 6:57 AM Timo Korhonen <Timo.Korhonen at ess.eu> wrote:
>
> 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!cGesPHlqnwLOnLQmQ_gkCNMswxM-xr3F-btQbM9uuazGaSRb8dY0O3J4as7R90K-y9L0luK4AGO37MjZU5wUI0SQ_KFA$ 
> (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.
> >
> >
>
>
>