Allow setting record options externally

[jacomago]

Checklist

• Testing:

  • The feature has automated tests
  • Tests were run
  • If not, explain how you tested your changes

• Documentation:

  • The feature is documented
  • The documentation is up to date
  • Release notes:
    • Added an entry if the change is breaking or significant
    • Added an entry when adding a new feature

[shroffk]

Is this a requirement from archiver appliance

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[jacomago]

Is this a requirement from archiver appliance

Yes! But also maybe alarms...

[kasemir]

...also maybe alarms...

We started out running the alarm server with

org.phoebus.pv.ca/monitor_mask=ALARM

Seemed logical, after all the alarm server only cares about changes in the alarm state.
But that means you won't see the current value of PVs when you list them in the alarm server console, since only changes that come with different alarm states will get through.
Also means that expressions for alarm filters will likely not get the expected behavior since they miss most value updates. OK, alarm filters were a bad idea anyway, should create appropriate alarm trigger PVs on the IOC in the first place. Still, switching monitors from VALUE to ALARM tends to create emails from surprised users.

[jacomago]

@mdavidsaver mentioned to me that he though the IOC should send the value updates as well and said he would aim to add that to pvxs. @mdavidsaver did you make an issue ticket for that?

Or of course we could define a new mask ALARM_WITH_VALUE?

[kasemir]

With channel access, the raw masks are bits which can be combined.
At a higher level, when we select "VALUE" for our preference, that turns into Monitor.VALUE | Monitor.ALARM on the CAJ level. "ALARM" is meant to reduce the updates so really just Monitor.ALARM, but as mentioned that's likely counterproductive, the default is better.

phoebus/core/pv-ca/src/main/java/org/phoebus/pv/ca/JCA_Preferences.java

Lines 88 to 98 in 7e3fbdf

	case "ARCHIVE":
	monitor_mask = Monitor.LOG;
	break;
	case "ALARM":
	monitor_mask = Monitor.ALARM;
	break;
	default:
	logger.log(Level.WARNING, "Invalid " + MONITOR_MASK + "'" + code + "'");
	case "VALUE":
	monitor_mask = Monitor.VALUE | Monitor.ALARM;
	break;

Should be the same with PVA: Default "VALUE" gets you any changes in the data. Certainly value changes, but also changes where only the status/severity change. "ALARM" would reduce it to only alarm changes. That option is pretty useless, but we keep it available.

"ARCHIVE" is like the default but at a reduced value change threshold.

[mdavidsaver]

@mdavidsaver mentioned to me that he though the IOC should send the value updates as well and said he would aim to add that to pvxs. @mdavidsaver did you make an issue ticket for that?

I believe this is related to the DBE mask for monitors. See epics-base/pvxs#97 . This DBE mask has the same meaning as with CA. So both dimensions of what (which fields) and when (which events) conditions can be specified in the pvRequest for a subscription.