Comment 6 for bug 1824277

>Is writing numbers to INP fields at run time a behavior that is documented by any sort?

In the calc record documentation under read parameters is states that the INP links can be initialized with constants and that dbPuts of constants will change its value. Then, under Operands, it states that A-L get their value from the value of the INP links and that the INP fields can be constants.

>What was written to 'INPA' was expected to appear in 'A'. Why not write to 'A' directly?

Because it is also expected to overwrite any existing linkage in INPA. When I change from a DB_LINK to a CA_LINK, all I have to do is push a different value to INPA and the previous link is removed and values are received from the new link. If I want to change from a DB_LINK/CA_LINK to a constant value, it should conceivably be the same process, just write a value to INPA and the record will lose the old link and update to a new value.

If we restrict constants to only being written to the operand fields, then not only does it mean that you have to remember to work with a different field when dealing with a certain datatype, but also you have to manually remove any existing links in INPA or else writing to the 'A' field just doesn't work because the record processes and your changed value is overwritten by the existing link's value.

>I would feel somewhat reluctant to actively retain a behavior that is undocumented and marks an inconsistency between record types. Feels like cementing an unwanted situation.

That's reasonable, however, the synApps sCalcout, aCalcout, transform, and luascript records all duplicate this behavior and from a quick check of a couple of our beamlines, there are definitely IOCs that are reliant on this. While it represents an inconsistency between record types, as argued above, it represents consistency in how the calc/calcout record behaves.