Comment 5 for bug 1824277

@Keenan, please correct me if what I wrote below is wrong, and point to any documentation you guys have that describe writing constant values to INPx fields...

I was slightly surprised, but this is behavior that our beamlines have apparently been using for run-time database configuration, and the BCDA group here have been incorporating the necessary special() processing code into many of the synApps record types for years. There is a sentence in the calcout wiki-page that says changing constants in the INPx links works; from https://wiki-ext.aps.anl.gov/epics/index.php/RRM_3-14_Calcout#Read_Parameters

> If they are constants, they will be initialized with the value they are configured with and can be changed via dbPuts.

BCDA provide general-purpose tools for visiting scientists to use, including GUI screens for configuring run-time calculations using calcout and other similar record types. Those screens need to have input boxes pointing to the INPx fields to get values from other records, and it makes perfect sense to allow constant values to be typed into those boxes instead of PV names. They have separate text widgets showing the associated value fields (and indicators pointing to the INxV fields that show whether the input link is valid/connected or not), but it is much simpler for the scientist if they don't have to use a separate editable widget for typing in constants.

There might be another way to support this, but it's a bigger change which could break other databases and I'm not so keen on it: The idea would be to have the CONSTANT link type actually return a value to a getValue() request (currently that routine exists but just returns OK without writing anything to the buffer). Numeric conversion from the string could be cached, so it would only be done once and shouldn't affect performance much (although an empty INPx field is a constant with value 0 so there might be some effect, dirtying a cache-line etc.).