Experimental Physics and
Industrial Control System

[email protected] (Tim Mooney) · Wed, 4 Feb 1998 17:21:48 -0600

I vote for a string version number (even though all the records I know of that already
have a .VERS field use Ned Arnold's float solution: integer part is major version number;
fractional part is minor version number).  Anybody who specifies a version string that
isn't lexically greater (as defined by strcmp()) than the previous version string would
get lots of mail.

One advantage of the string alternative is that it allows us to include the EPICS version
number.  (Few people know offhand that you can't use version 2.x of the motor record with
EPICS 3.13, or version 3.x with 3.12.)  The version strings 3.12.02:2.5 and 3.13.00:3.2,
though ugly as sin, convey quite a lot of useful information and are lexically in order
(as long as we never have 3.13.100).

Tim

> I suspect that storing the version in a record type specific string would result in too
> much flexibility. How will CA client applications determine if the version is greater
> than some number without making the string parsing code specific to the particular 
> record type.
> 
> I am still in favor of two integer pseudo fields for the version info. One for
> the major version number and one for the minor version number. This
> would require a slightly different API.
> 
> dbCreateRecordTypeAttribute (char *recordtype, char *name, unsigned DBF_type, void *value);
> 
> Jeff
> 
> On Wednesday, February 04, 1998 7:27 AM, Marty Kraimer [SMTP:[email protected]] wrote:
> > OK maybe we can have the best of both worlds.
> > 
> > How about this.
> > 
> > We keep the new DBR_CLASS_NAME request.
> > 
> > In addition the following is implemented:
> > 
> > A new database access routine is provided:
> > 
> > dbSetRecordTypeAttribute(char *recordtype,char *name,char *value);
> > 
> > For example:
> > 
> > dbSetRecordTypeAttribute("mySpecialRecordType","VERS","25.56.456")
> > 
> > Runtime Database access will automatically create attribute RTYP, e.g. 
> > 
> > dbSetRecordTypeAttribute("ai","RTYP","ai");
> > 
> > In addition dbNameToAddr (the routine called to locate records a
> > runtime)  will be modified as follows:
> > 
> > If the record is found but the field is not found then it checks to see
> > if the field name is one of the attribute names. If it is it makes a
> > "psuedo" field that looks like the following
> > 
> > 1) The field type is DBF_STRING
> > 2) It can not be changed, i.e. puts will fail.
> > 3) The value is the attribute value.
> > 
> > Since dbNameToAddr only does this in the case where it finds the record
> > but not the field, the overhead on an ioc is minimal.
> > 
> > Marty Kraimer
> > 
> > Jeff Hill wrote:
> > > 
> > > > >From the responses to the message I sent about RTYP there are objections
> > > > to implementing RTYP via a new DBR_type rather than a new field in each
> > > > record instance.
> > > >
> > > 
> > > There is nothing stopping us from having both a new DBR_xxx type and also a new
> > > pseudo field name which has storage in the record description, but not in the record
> > > instance. It appears that there are important uses for both interfaces to the
> > > system (i.e. links use the new field names, and general purpose clients that do not
> > > wish to break when the PV name syntax varies will use the new DBR_ type).
> > > 
> > > Jeff Hill
> > 
> > Chip WATSON wrote:
> > > 
> > > Marty,
> > > 
> > > Would it be possible to create a pseudo-field accessable via record.RTYP
> > > but which is in fact
> > > implemented in record type structures?  Specifically, when the channel
> > > access server locates
> > > the record, and discovers it does not have a field of that type, it
> > > could, before returning an error,
> > > check if the field name is one of the allowed pseudo-fields (RTYP, VERS,
> > > etc.).
> > > 
> > > Chip

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System