Comment 7 for bug 1777768

I had another report of this behavior from an APS developer.

He has an aSub record which is writing a scalar from VALA via a DB link in OUTA to a passive ai record. He has to set the PP flag on the OUTA link for his OPI screens to see the change in the ai.VAL field, even though a caget of that field demonstrates that the put has succeeded. If he was writing to any field other than VAL there would be no need to set PP for monitors to fire automatically and the OPI screens to update.

I take Ralph's point that not processing the record results in its timestamp never getting set and alarms never being checked, which are good reasons to tell users they should be setting PP. However this is evidently a cause for user confusion. Before I withdraw this bug is there any way we can help users to understand the current behavior better? The confusion is caused by the isValueField conditional towards the end of dbPut():

    if (precord->mlis.count &&
        !(isValueField && pfldDes->process_passive))
        db_post_events(precord, pfieldsave, DBE_VALUE | DBE_LOG);

I note that DB links don't have any way to say "follow the target field's pp() setting" although that could be implemented relatively easily with a new (RPP or TPP?) link flag. Would it be worth adding something like that? I might even be inclined to make that the default in the absence of either PP/NPP flag, but doing so might need a warning at load-time to avoid breaking too many existing databases.