g+
g+ Communities
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  Index 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Re: EPICS r3.13 fields RTYP/VERS
From: mooney@aps.anl.gov (Tim Mooney)
To: tech-talk@aps.anl.gov
Date: Fri, 9 Jan 1998 15:00:57 -0600
re...

> > ...(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.

That's a good idea.  It does seem silly to use a field for this purpose.

> > 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.

That's true only if they're running in the same ioc.  It's an advantage for end
users to be able easily to find out which version of record/device support
they're running, so they can tell tech support on the phone.

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

It's flat-out impossible to keep scores of ioc's with different maintenance
schedules on the same version of everything.  We try pretty hard to do this; if
we tried much harder, we'd have no time at all for development.

You might be thinking of an EPICS installation in which one person has control,
builds once, and builds correctly.  But with lots of EPICS installations
involving lots of custom records and device support continually being enhanced,
maintained by lots of people with different areas of expertise, there's plenty of
opportunity for mismatched .dbd's and record/device support modules.  It happens
frequently enough to be a tech-support issue for us and it's sometimes a very
hard problem to diagnose.  (The amazing thing, by the way, is that EPICS works
well in this free-for-all shared-development atmosphere--*much* better than
anything else I've seen or heard of.  In fact, EPICS appears to have been
designed for this.)

Tim Mooney

Navigate by Date:
Prev: RE: EPICS r3.13 field DESC length Jeff Hill
Next: Re: EPICS r3.13 fields RTYP/VERS Mark Rivers
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: Bookmark to EPICS software distribution Bakul Banerjee
Next: Re: EPICS r3.13 fields RTYP/VERS Mark Rivers
Index: 1994  1995  1996  1997  <19981999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·