Re: RTYP field through the PV Gateway

[Ralph Lange <Ralph.Lange@bessy.de>]

Hi Andrew,

sorry for being smartass without looking at the code - I'm still on 
vacation, at home, without a full-size computer that would be able to 
run a reasonable editor or EPICS. The EPICS/CA code just doesn't fit 
onto my PDA screen....

Good to hear that RTYP is a database attribute and the .VAL extension is 
implemented in the database.
Does that mean that the CA client doesn't do anything special and doing 
a "caget XXX.RTYP" issues a value DBR type request?

Ernest: Why do you see a DBR_CLASS_NAME request at the Gateway, then?

Cheers,
Ralph


Andrew Johnson wrote:
> Hi Ralph,
>
> On Thursday 08 January 2009 07:56:53 Ralph Lange wrote:
>   
> > RTYP is a pseudo field: When a read request for a "*.RTYP" PV comes in,
> > the CA client library  strips the ".RTYP" and converts it to a
> > DBR_CLASS_NAME request.
> >     
>
> Wrong, RTYP is one of two standard Record Attributes, pseudo-fields supported 
> by the database whose values are specific to the record type and can be set 
> (and new attributes created) using dbPutAttribute().  If the .RTYP handling 
> was an artifact of CA like you suggest I wouldn't be able to do this from the 
> ioc shell:
>
> epics> dbgf mrk:stringinsyn.RTYP
> DBR_STRING:          "stringin"
>
> Go read section 6.14 of the AppDevGuide.  Attributes have been part of the IOC 
> since at least R3.13.0, just nobody uses them much...
>
>   
> > The only other case of CA-EPICSdb dependency (that I know of) is adding
> > the ".VAL" extensionsto PVs without a field name. I don't know if this
> > is done by the client or the server right now - it should be done on the
> > server side for the same reasons.
> >     
>
> Nothing explicitly adds .VAL to the PV name; when someone [currently RSRV, by 
> calling db_name_to_addr()] presents a PV name to dbNameToAddr() if the name 
> doesn't contain a field part it looks up the "VAL" field automatically.  Thus 
> this is already done in the server.
>
> - Andrew
>