Comment 5 for bug 1777768

Load this database:

record(ai, target) {
  field(TPRO, 1)
}
record(ao, put-val) {
  field(OUT, "target.VAL NPP")
}
record(ao, put-rval) {
  field(OUT, "target.RVAL NPP")
}

Start "camonitor target.VAL target.RVAL".

Compare the difference in camonitor output between doing "dbpf put-val 1" (no monitor triggers) and "dbpf put-rval 1" (monitor is triggered on the RVAL field). In neither case is the target record actually processed (no output from having set TPRO) so the timestamp is still <undefined> as it should be, but clients monitoring both fields only get notified when the RVAL field changes, not for VAL.

I don't see any implications for PVA links, although there might be for QSRV if it allows a client to put to a field without triggering record processing. I assume it's using the dbChannel API to talk to the database; if it always calls dbChannelPutField() then QSRV is going to behave like RSRV and the pp() attribute of the field determines whether the record gets processed or not.

If QSRV calls dbChannelPut() then it gets to decide whether to process the record or not (and it has to do that itself). In both cases though the underlying dbPut() routine that writes to the field will call db_post_events() on the field, unless the field is VAL and the pp() attribute is true. For external CA clients that logic is appropriate because the record's process() routine will call db_post_events() soon afterwards anyway, and this avoids sending two monitor events.