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  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 
<== Date ==> <== Thread ==>

Subject: Re: dbst problem when built against 3.13.1(actually problem with capfast symbols)
From: wright@odin.atdiv.lanl.gov (Rozelle Wright)
To: tech-talk@aps.anl.gov
Date: Mon, 1 Feb 1999 13:13:57 -0700
> From saa@SLAC.Stanford.EDU 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: tech-talk@aps.anl.gov
> X-Vms-To: IN%"tech-talk@aps.anl.gov"
> 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 
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 
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 ·