Question: CA monitor event and timestamp handling on compress record reset

["Kim, Kukhee via Tech-talk" <tech-talk at aps.anl.gov>]

Hello EPICS community,

I’d like to ask for guidance regarding a possible issue (or design choice) in the compress record reset behavior.

In a use case involving long-term data collection, a compress record is triggered infrequently (e.g., ~10-minute intervals) to capture very slow source-side events (~Hz) over weeks to months. After a long accumulation period, the compress record is reset using:

.RES = 1

This correctly clears the internal ring buffer and sets NUSE = 0. However, we observed that Channel Access monitors (e.g., camonitor) do not receive an update at the time of reset. The reset becomes visible to CA clients only after the next compress trigger occurs.

From initial inspection, it appears that the reset path (handled in special() in the compress record support) clears internal state but does not generate a CA monitor event.

One possible approach would be to explicitly call monitor() after handling the reset in special(). However, this raises a question about timestamp semantics:

• If a reset is treated as a form of record processing, should we update the timestamp (e.g., via recGblTimeStamp(prec)) before calling monitor()?
• Alternatively, if reset is considered a configuration/state change rather than data acquisition, is it preferable not to update the timestamp and simply notify clients of the state change?

I’d appreciate any guidance on the intended behavior here, or whether there is an established pattern in EPICS Base for handling CA monitor events and timestamps in reset-style operations.

Thank you very much for your time and insight.

Best regards,
Kukhee

SLAC National Accelerator Laboratory