Comment 3 for bug 1844537

Below is a diff against commit f3204d8afad49b6f3aa375f7efe705e3b2f68229 for the doc fix.

We just checked that the behavior in 3.15. and 7.0 is the same for all records that have DOL and OMSL: if DOL is constant, OMSL="closed_loop" is ignored and the behavior is as if OMSL="supervisory". And modifying a constant link with a CA put has no effect other than that the value of the DOL field changes.

Your comment regarding the many changes to link support prompted me to look at the new dbLink.h. It looks as if the existing anomalous behavior of constant links is now hard-coded into the design of the LSET interface. This makes it indeed more difficult to implement the change I sketched above.

diff --git a/modules/database/src/std/rec/boRecord.dbd.pod b/modules/database/src/std/rec/boRecord.dbd.pod
index 8df8d7f..6b6d180 100644
--- a/modules/database/src/std/rec/boRecord.dbd.pod
+++ b/modules/database/src/std/rec/boRecord.dbd.pod
@@ -65,9 +65,9 @@ C<losed_loop> or C<supervisory>. If C<supervisory> is specified, the value
 in the VAL field can be set externally via dbPuts at run-time. If
 C<closed_loop> is specified, the VAL field's value is obtained from the
 address specified in the desired output location (DOL) field which can be a
-database link, a channel access link, or a constant. To achieve continuous
-control, a database link to a control algorithm record should be entered in
-the DOL field.
+database link or a channel access link, but not a constant. To achieve
+continuous control, a database link to a control algorithm record should be
+entered in the DOL field.

 L<Address Specification> presents more information on database addresses
 and links. L<Scanning Specification> explaines the effect of database