Experimental Physics and
Industrial Control System

Marty Kraimer <[email protected]> · Mon, 23 Mar 1998 08:09:21 -0600

Steven M Beard wrote:
> 
> I have just run into a problem with the subRoutine record, and I am
> grateful to Andy Foster (of the Royal Greenwich Observatory) for
> suggesting a solution. Here it is in case anyone else meets this problem.
> 
> The symptoms were as follows:
> 
> 1) The database file, m2.db, contained a subRoutine record with the
>    following field
> 
>         record(sub,"m3:interlock") {
>                 field(SNAM,"interlockMonitor")
>         }
> 
> 2) After the database was loaded, the following error appeared on the
>    console when iocInit() was executed
> 
>    Subroutine not found PV: m3:interlock  recSub(init_record)
> 
>    Normally this error would be due to the subroutine declared in the
>    SNAM field not matching a subroutine in the VxWorks symbol table.
>    However, this time the subroutine interlockMonitor definitely existed.
> 
> 3) When the  database record was examined with
> 
>       dbpr "m3:interlock"
> 
>    it looked as if the SNAM field of this record had been corrupted!
> 
> It turns out that the SNAM field of the subroutine record can only store
> up to 16 bytes (15 characters plus a NULL terminator). The name of the
> subroutine interlockMonitor is exactly 16 characters long, which meant it
> could be stored in the SNAM field but the NULL terminator was missing.  It
> looks like both "iocInit()" and "dbpr" came across this string and kept
> reading garbage characters until they found a NULL terminator. Andy
> Foster's solution was to reduce the length of the subroutine to 15
> characters or less.

I changed the length for sub and gsub. The next release will have size
set to 40 characters for both SNAM and INAM.

> On examining the .ascii files in the EPICS 3.12.2 distribution I am using,
> it turns out that some records allow the SNAM field to have up to 40
> characters and others only allow SNAM to have 16 characters. I would find
> it less confusing if all the records which used a particular named field
> defined that field to have consistent properties (e.g. having SNAM 40
> characters everywhere).

Yes this would be nice. A problem is that record support for various
record types is supplied by different people at different sites.

> Even better, would it be possible for every
> string-type field in an EPICS database to be up to 40 characters long,
> rather than having different fields different lengths?

Although nice this will cause other problems. For example the state
strings for binary records. db_access defines a structure for passing
the complete set of "menu" choices to a client. The set of state choices
for binary records is sent to the client via this structure. The
structure only allows for 16 character strings. Thus no easy solution.

Some day we want to allow arbitrary length character strings. This will
probably not happen until Channel Access Version 4.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System