EPICS Controls 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  2021  2022  2023  2024  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  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS r3.13 fields RTYP/VERS
From: Ralph Lange <[email protected]>
To: [email protected] (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  2021  2022  2023  2024 
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  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 ·