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
<1998>
1999
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
<1998>
1999
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
|