Experimental Physics and
Industrial Control System

Rozelle Wright <[email protected]> · Thu, 3 Feb 2000 10:17:26 -0700 (MST)

Capfast doesn't make DOL default to 0, the primitive symbols used by capfast do.
At Los Alamos we modified all the capfast symbols files so
that DOL is by default empty.  We did the same thing for all the other
link fields. INP, OUT, etc.  
I used a perl script and changed all the patterns def(DOL):.*  to def(DOL):
and similarly for the INP, INPA, OUT etc.

Rozelle
[email protected]

> From [email protected] Thu Feb  3 06:10 MST 2000
> Sender: [email protected]
> Date: Thu, 03 Feb 2000 14:08:21 +0100
> Organization: BESSY
> X-Mailer: Mozilla 3.0 (X11; I; HP-UX B.10.20 9000/785)
> MIME-Version: 1.0
> To: [email protected]
> Subject: Re: VxWorks global variable device support
> References: <[email protected]>
> Content-Transfer-Encoding: 7bit
> X-Lines: 49
> 
> William Lupton wrote:
> > 
> > Ralph,
> > 
> > ------------------------------------------------------------------------
> > Re how to control initialization of output records:
> [...]
> > >3. PINI = YES, DOL is not set
> > >   Read back the variable value at startup. (I.e. the application set it
> > >   to some meaningful value before record initialisation.)
> > 
> > So, the variable value is read back at startup only in the last case. So
> > this could happen inadvertently if:
> > 
> > a) there is a tool out there which defaults DOL to "not set" rather than to
> >    "constant zero" (we agree that Capfast is not such a tool; maybe there
> >    are no such tools)
> > 
> > b) someone has previously created a database with DOL set to an empty or
> >    blank string (which will be interpreted as "not set") and has _intended_
> >    that to be the initial value written (this would probably be unintentional
> >    for anything other than a stringout?)
> 
> As regards (a), there is definitely a tool out there, it's called DCT.
> At least in the newest version it does not initialize DOL to anything if
> you don't explicitly specify so. I'd say that defaulting DOL (or any
> other link field) to "not set" is the correct behavior since 3.13, at
> least that's what the release notes suggest.
> 
> So, IMHO, case (a) is the rule rather than the exeption. Case (b) should
> be regarded as an error in the database design, at least for databases
> that are supposed to be 3.13 compatible (see, again, release notes for
> R3.13).
> 
> I want to add a remark on Capfast: Neither the program itself nor the
> conversion tools have any defaults for record fields. It's the symbols
> (*.sym) and the edb.def that determine which fields are set by default
> and to which value. The old behavior was to initialize all link fields
> to something like "0.000000000" (lots of "0"s, never understood why).
> 
> To make Capfast compatible with 3.13, I went through the work of
> adapting the symbols and the edb.def for R3.13.1 (or whatever release
> number actually introduced differentiating between "0" and "" for
> links). The changes (i.e. throwing out any defaults with a zero value)
> can be done automatically with little perl script.
> 
> Ben
> -- 
> The Notorious Neb Nesknarf
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System