This is an EPICS bug report.
Affected versions:
Probably all recent EPICS versions.
Likely symptom:
After disabling, writing a value, and reenabling a passive record using
Channel Access puts to its DISA field (e.g. as part of a snapshot file
restore or a bumpless reboot procedure) local DB OUT links with
attribute PP will continue to write the value to the record, but won't
process it.
As soon as some application does a CA put to the record, things get back
to normal, i.e. local DB OUT links with PP attribute will write the
record value and process.
Analysis:
When the record's value is written while it is disabled, its PUTF field
is set (in dbPutField), while the code that usually resets the field (in
recGblFwdLink) is not executed because the record is disabled.
After the record is reenabled, any DB OUT link pointing to it will
interpret the PUTF field still being TRUE (in dbPutLinkValue) as an
asychronous record processing being active. So it will register an apply
for reprocessing by setting the RPRO field instead of instantaneously
triggering processing of the destination record. As the record is not
active, is is never processed.
Any CA put to the record doesn't care about the PUTF field, processes
the record and after PUTF is reset (in recGblFwdLink) subsequent DB
links to the record will work as expected.
Workaround:
Setting the OUT link attribute to CA instead of PP in the database that
tries to trigger the record will yield the desired behaviour regardless
of the record's disable history.
Possible fixes:
- dbPutField does not set the PUTF field if the record is disabled.
- dbPutLinkValue checks PACT instead of or in addition to PUTF to
determine an active asynchronous processing.
Looking at the limited use of the PUTF field in EPICS base I would
suggest throwing out this field completely. At least in 3.14 - to make
more room for C++ code.
As I'm not too well aware of dangerous side effects I would like the APS
database gurus to decide how this is to be solved.
Happy processing,
Ralph