Re: bo Record not forcing VAL to 0 or 1

[Bruce Hill <bhill@slac.stanford.edu>]

Hi Andrew,
The record already protects itself from caput or dbpf with values > 1, so a DOL link
may be the only way to set VAL to be other than 0 or 1.

If no-one has replied to you that they need this behavior,
I'd like to propose it get fixed in the next release.

The fix is simple, and works at my site.

--- boRecord.c  (revision 3756)
+++ boRecord.c  (working copy)
@@ -202,7 +202,7 @@
                        status=dbGetLink(&pbo->dol,DBR_USHORT, &val,0,0);
                        pbo->pact = FALSE;
                        if(status==0){
-                               pbo->val = val;
+                               pbo->val = val == 0 ? 0 : 1;
                                pbo->udf = FALSE;
                        }else {
                                        recGblSetSevr(pbo,LINK_ALARM,INVALID_ALARM);


Best regards,
- Bruce

On 1/25/2011 4:13 PM, Andrew Johnson wrote:
> Hi Bruce,
>
> On Monday 24 January 2011 23:14:02 Bruce Hill wrote:
> > In all the bo record documentation I can find, record processing specifies:
> > > if DOL is DB_LINK and OMSL is CLOSED_LOOP
> > >
> > >      * get value from DOL
> > >      * check for link alarm
> > >      * force VAL to be 0 or 1
> > However, the boRecord.c source code for 3.14.9 and 3.14.11 does not do
> > this. If you read a non-zero value from the DOL link, VAL and RVAL
> > retain that non-zero value, even if it isn't a 1.
> >
> > Does anyone know if this is intentional, or a bug?
> I think this is a bug, but I'm not certain whether it's in the code or the
> documentation.  I just checked the history all the way back to the beginning
> of time (well, to when Marty first added the boRecord code to CVS in 1995) and
> the VAL field has never been forced to be 0 or 1 during record processing.
> Interestingly the forcing does happen at record initialization when DOL is a
> constant.
>
> If VAL is neither 0 nor 1 then ca_get as a string returns "Illegal_Value" and
> RVAL is set to VAL; the behavior of RVAL is correct if the device support has
> set MASK, RVAL is MASK for all non-zero VALs else zero.
>
> Should we fix this in the 3.15 series?  Does anybody know of any databases
> that rely on this weird behavior?
>
> - Andrew