Before I was thinking of a different special condition from dbPutField() which I do replicate in QSRV to decide whether a Put should dbProcess(). (since I can't use dbPutField() with groups) In the case of QSRV, this is a default which the client can override with 'record._options.process' in a pvRequest blob.
wrt. PP/NPP while I don't like these (seemingly) odd conditions in dbPut() or dbPutField() or dbNotify. Working around one by adding another to dbDbPutValue() does not seem like a sustainable way forward.
Looking back...
wrt. QSRV
Before I was thinking of a different special condition from dbPutField() which I do replicate in QSRV to decide whether a Put should dbProcess(). (since I can't use dbPutField() with groups) In the case of QSRV, this is a default which the client can override with 'record. _options. process' in a pvRequest blob.
> if (paddr->pfield == &precord->proc || >process_ passive &&
> (pfldDes-
> precord->scan == 0 &&
> dbrType < DBR_PUT_ACKT)) {
wrt. PP/NPP while I don't like these (seemingly) odd conditions in dbPut() or dbPutField() or dbNotify. Working around one by adding another to dbDbPutValue() does not seem like a sustainable way forward.