Re: wrong timestamps in monitors

[Maren Purves <m.purves@jach.hawaii.edu>]

On Tue, 3 Feb 2009, Benjamin Franksen wrote:
> On Monday 02 February 2009 23:18, Maren Purves wrote:
> > Benjamin Franksen wrote:
> > > On Montag, 2. Februar 2009, Till Straumann wrote:
> > > > Benjamin Franksen wrote:
> > > > > Our idea for an efficient implementation is based on the observation
> > > > > that in a typical EPICS database there are only very few fields per
> > > > > record that actually receive dbPuts (or get updated directly from
> > > > > within base). Only for these fields is it necessary to provide
> > > > > storage for the time of the last update. This storage will be
> > > > > allocated on demand; each record must maintain a (typically very
> > > > > short) list of (field index, timestamp) pairs; let us call it the
> > > > > 'field update list' or short 'update list'. When reading the
> > > > > timestamp for a field, first search the update list and use the
> > > > > contained stamp if one is found, otherwise use the TIME field of the
> > > > > record.
> > > >
> > > > How does that implement (b) ? If a field is never updated,
> > > > shouldn't that field then report the time when iocInit() was
> > > > executed?
> > >
> > > Ah, a good objection. It looks as if we need to distinguish between
> > > fields that have
> > >
> > >  i)   never been changed (timestamp = iocInit time)
> >
> > only if PINI=Yes?
>
> Surely not. Every field gets initialized at startup. PINI should be treated
> like all other processing.

I use TIME=0000 (etc., not sure about exact format) in trouble shooting
new stuff a lot, and I'd like to have it kept as a feature for records
when PINI is NO. It's much easier to find all the zeros than the UDF
field.

You can see that as a feature request, and if people disagree, then,
obviously not. But for me it's a "nice to have".

Aloha,
Maren