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 field VERS
From: Jeff Hill <[email protected]>
To: "'Marty Kraimer'" <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 3 Feb 1998 13:10:53 -0700
Since all records of a particular type in a particular IOC will have the same version
then it appears to be overkill to allocate a field in db common for the version information.
I suggest that the record support call a routine supplied by db common during
the record type specific init to specify the major and minor version numbers.
If this routine is not called then the version numbers would default to zero.
This will allow us to store the version information with the record type description and
not with the record instance. We could access the version information through two 
pseudo fields "majv" and "minv" which do not really exist in the record instance, and 
also perhaps through CA client data types. No change would be required to existing record 
support that does not yet supply the version information.

Jeff Hill

On Tuesday, February 03, 1998 10:25 AM, Marty Kraimer [SMTP:[email protected]] wrote:
> There seemed to be a consensus that it is a good idea to have a field
> VERS in each record. There was no consensus about how this field is
> given a value. The only ways I see that are easy to implement are:
> 
> 1) Give an initial value in the .dbd file
> 2) make the developer give a value via the init routine of the record
> support module.
> 
> I originally suggested 1) but have changed my mind. Either it is done
> automatically or the developer has to remember to change the .dbd file
> when any change is made in the record support module. In spite of some
> suggestions I dont see an easy way to do it automatically. Note that
> version should change ONLY when the .dbd file or record support module
> are changed. The developer is likely to forget to change the .dbd file
> when only the record support module is changed. Thus I vote for 2).
> 
> This means that we could put something like
> 
> field(VERS,DBF_STRING) {
>     prompt("Version Number") 
>     special(SPC_NOMOD)
>     size(40)
> }
> 
> This could go into dbCommon
> 
> Then a record support init_record routine could contain:
> 
>     strcpy(precord.vers,"xxx.yy");
> 
> Questions:
> 1) Should the field type be DBF_STRING?
> 2) Should there be rules about how version numbers are assigned?
> 3) What about all the existing record support modules?
> 
> Marty Kraimer

Navigate by Date:
Prev: Re: EPICS r3.13 field VERS Marty Kraimer
Next: RE: EPICS r3.13 field VERS 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 
Navigate by Thread:
Prev: Re: EPICS r3.13 field VERS Marty Kraimer
Next: RE: EPICS r3.13 field VERS 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 ·