Re: FLNK length limit

["Johnson, Andrew N." <anj@aps.anl.gov>]

Hi Lewis,

On Feb 9, 2018, at 10:44 AM, J. Lewis Muir <jlmuir@imca-cat.org> wrote:

Andrew answered a similar question in 2006 in:

 https://epics.anl.gov/tech-talk/2006/msg01310.php

There he said:

 I would also suggest that you try *really* hard to limit your record
 names to the maximum recommended 28 characters.  You *can* make them
 longer (up to 60 characters), but until the EPICS 40 character string
 length limit goes away (which means until the Channel Access protocol
 gets revised and the database and all of the tools are modified to use
 variable length strings) using longer names *will* end up causing you
 difficulties.

Since it's 2018 now, all those modifications have occurred, right?

Effectively yes, since we can now get/put string fields as char arrays. This didn’t actually require changes to the CA wire protocol and we don't now plan to ever enlarge the Channel Access 40 character DBF_STRING type.

In the same post, Andrew went on to say:

 Why is the recommended limit only 28 characters?  Well if you want to
 change a link field via Channel Access you only have 40 characters to
 hold the complete link value, and as well as the record name the link
 might need dot field name (5 chars with the standard record types) and
 the flags NPP/PP/CA/CP/CPP and NMS/MS which will need another 7 chars
 (you can omit the space between them if necessary, but not the one
 that terminates the field name).  That leaves just 28 characters for
 the name, and yes I am allowed to leave the terminating \0 byte out of
 that calculation.

Applying the same logic to allow for the dot, field name, and flags,
would make for a new effective *record name* length limit of 48 (60 -
12) characters.

No, the record name length is the independent variable and is currently 60 chars plus the nil terminator. Your 60-12 calculation would only apply if it was the size of CA’s DBF_STRING type we were changing to 60, but inside the IOC we can make string fields any size we like (if you look at the mbb* records the **ST fields are now all 26 characters long for example, because the internal dbAccess API supports enum strings up to that size, although CA only transports up to 16 characters). The CA protocol allows channel names to be any length, but there is probably a limit if you get too close to the maximum UDP packet size though.

However, with support for writing a link field over
Channel Access as a byte waveform, I do not need to allow for the dot,
field name, and flags anymore.  So, the effective *record name* length
limit is still 60 characters (excluding the terminating null character).
The byte waveform written over Channel Access to a link field could be
72 characters (or more if there are spaces between the flags).  All
correct?

Yes, although I prefer the term “char array” to “waveform” which is the name of a record type with an array as its VAL field.

Note that in earlier Base versions there is still a limit to the size of string you can put to a link field, which matters when you’re adding JSON field modifiers to the link address text – in 3.14.12 it’s 80 characters, 3.15.5 allows up to 256 characters. From 3.16 that fixed size buffer has gone away though.

HTH,

- Andrew