EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: dbst problem when built against 3.13.1(actually problem with capfast symbols)
From: [email protected] (Rozelle Wright)
To: [email protected]
Date: Mon, 1 Feb 1999 13:13:57 -0700
> From [email protected] Mon Feb  1 12:23 MST 1999
> Date: Mon, 01 Feb 1999 11:20:34 -0800 (PST)
> Subject: dbst problem when built against 3.13.1
> To: [email protected]
> X-Vms-To: IN%"[email protected]"
> X-Vms-Cc: SAA
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7BIT
> X-Lines: 23
> 
> Hello -
> 
> Recently, I rebuilt a subset of extensions against R3.13.1 
> (with a little more effort than anticipated - I thought it would 
> be a matter of changing a few CONFIG files and rebuilding - Not!).
> So far, the extensions that we use are all working as before except
> for dbst, the tool that checks .db files and strips out unnecessary
> lines.  I believe dbst is used mostly by people who generate .db
> files from CAPFAST schematics via e2db.  
> 
> The R3.13.1 dbst does not strip out fields that are initialized to 
> zero.  As a result, the .db files it generates are significantly 
> bigger and IOCs take longer to reboot.  Also, it can affect bumpless 
> reboot if you restore your subroutine/calc inputs before 
> InitHookafterInitDatabase (the zeros will override what you restore 
> for these).
> 
> Has anybody seen this problem and fixed it?  My first guess is that 
> there is a change to some dbStatic routine that is called by dbst.
> 
> Thank you,
> 
> Stephanie Allison
> 
Hi Stephanie,
I haven't changed dbst, I simply report out fields that are different
from the default.  It is
possible that dbStaticLib has changed.  
I believe the problem is that global link fields are  really strings, 
so the default is the empty string rather
than 0.00000000000e+00 (as it appears in all the capfast symbols).
I had a problem with DOL fields inadvertantly initializing analog out
records to 0.0.
I went through  and did a global edit on .sym files
that have DOL fields  and changed def(DOL) from 
def(DOL):0.000000000000000e+00 
to 
def(DOL):
This fixed our problem with analog outs.  
However, I think this should probably be done for all the other LINK fields.
INP, FLNK, INPA, INPB   etc.

Rozelle

Navigate by Date:
Prev: dbst problem when built against 3.13.1 saa
Next: Notes on building extensions against R3.13.1 base saa
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: dbst problem when built against 3.13.1 saa
Next: Re: dbst problem when built against 3.13.1(actually problem with capfast symbols) saa
Index: 1994  1995  1996  1997  1998  <19992000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·