Re: calc record odd behavior

[Ralph Lange via Tech-talk <tech-talk@aps.anl.gov>]

On Tue, 29 Jan 2019 at 18:00, Johnson, Andrew N. via Tech-talk <tech-talk@aps.anl.gov> wrote:

On 1/29/19 10:09 AM, Bruno Martins via Tech-talk wrote:
> CALC's value is initially 1, as expected. However, if I do "caput CALC
> 0", a monitor event is never issued again when CALC.VAL goes back to
> being 1. Shouldn't a monitor event be issued in this case?
Your "caput CALC 0" is pointed at the VAL field, which has some special
handling.
[...]

One could say that the VAL field of a CALC record is not intended to be written to, as its value will always be updated by the result of the calculation.

The same effect (with the same possible surprise about unexpected behavior) applies to all output record types that don't consider VAL as the original source of the value to write, but calculate VAL using some algorithm, e.g. from base:

• the calcout record as it does the same as the calc,
  
• the mbboDirect record that overwrites VAL with the or'ed up Bn fields,
  
• the sel record that overwrites VAL with the result of the selection algorithm.
  

Would making the VAL field SPC_NOMOD make the behavior more clear by rejecting writes? Feels like it could have side effects that break existing databases, though...

Cheers,
~Ralph