Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  <19981999  2000  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  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: EPICS r3.13 fields RTYP/VERS
From: Ralph Lange <lange@ash.acc.bessy.de>
To: tech-talk@aps.anl.gov (EPICS Tech-Talk)
Date: Fri, 9 Jan 1998 11:20:59 +0100 (MET)
> I think it would be a bad idea to set the record's version number in the .dbd
> file anyway.  (It might not be so bad for the .dbd file to have its own version
> number, so record-support could verify that it wasn't compiled against an
> outdated header file.)

Since this can be checked at compile time, it should. There's no need to
have a runtime field for the dbd version in each record. If there was a
general way to include something in the database definition like

recordtype(record_type) {
  define(TAG, "value")

which gets

#define record_typeRecordTAG value

in the header file, record support could easily check anything it wants to
at compile time or runtime.

> Anyway, I'm in favor of every record having a VERS field.
> [...]
> I think the device support's version number should also be available via
> channel access.

If there are two different versions of one record or device support running
in parallel, their record type or DTYP must be different, so having a
version field would be redundant.

Is it really wanted two have different IOCs running different versions of
the same record or device support? (*Shudder*)

About a field or function getting the record type:
This would make it easier for multi-record-type device support functions to
efficiently retrieve the type of the record they are called by. [For the
time being I'm abusing the init_record() function called with NULL for
that.]

Ralph

References:
Re: EPICS r3.13 field DESC length Tim Mooney

Navigate by Date:
Prev: Re: EPICS r3.13 field DESC length Tim Mooney
Next: developing Gpib devSupport mauro
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: EPICS r3.13 field DESC length Tim Mooney
Next: RE: EPICS r3.13 field DESC length Jeff Hill
Index: 1994  1995  1996  1997  <19981999  2000  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 ·