This refers to a structured area within which data is returned by the fast data access service. The calling application must provide specific control information in the buffer before passing it to a service. IEWBUFF - Binder API buffers interface assembler macro for generating and mapping data areas defines an IEWBUFF assembler macro that can be used to allocate, map, and/or format the buffer correctly (see that topic for details). Binder API buffer formats contains details of all buffer type formats. Note that multiple buffer format versions exist. These should not be confused with program object versions. With a few exceptions, fast data is able to map data from any program object version into any buffer format version; however, earlier buffer format versions may be missing fields for features available in more recent program objects. In general, an application should use the most recent buffer version supported by the systems the application is designed to run on. Earlier PO formats can always be represented in more recent buffer formats.

There were major changes between PO1 and PO2 object formats, and corresponding major changes between version 1 and version 2 buffers. Because of this, version 1 ESD, RLD, and NAME buffers cannot be used to access more recent program object versions. If using IEWBUFF to generate buffers, please note that for compatibility the default remains VERSION=1. Applications should override that default in most cases.

Every buffer type has a header which identifies the type and version of the buffer. Three other fields within the buffer headers deserve special note:

BUFFER_LENG

The total length of the buffer in bytes, including the header. Data entries are built following the header, but the total buffer size must also include space, in many buffer types, for name strings. These are built in descending address order working back from the end of the buffer. It should be noted that the binder supports external symbol names up to 32,767 bytes long, and that some entry types have multiple names for a single entry. An application written to support arbitrary names needs to provide a buffer which is large enough to handle any combination of names associated with a single entry. An ESD entry, for example, can have up to four names associated with it, so in theory the buffer might have to be more than 128 KB long to retrieve a single entry.

ENTRY_LEN

Data will be returned as an array of entries. For example, External Symbol Dictionary entries are currently from 56 to 96 bytes long, depending on buffer version, but within a single buffer all ESD entries are of the same length. The length is an attribute of the buffer version, and must correspond with it. A few buffer types, including text buffers, effectively have unstructured or varying length blocks of data. These buffer types always use an entry length of 1, meaning that their content is counted in bytes.

ENTRY_COUNT

This is a nominal number of entries that can be expected to fit in the buffer. The product of the entry count and the entry length is the size anticipated to be used by returned data, excluding symbol names. The entry count is not updated on return from a service, so it does not indicate the number of entries that are actually in the buffer. See the Count parameter below for that. The count returned could be less than this entry count even when there are more entries that have not yet been returned. This would happen if the name strings for the entries returned require more space than was reserved at the end of the buffer for them. In some cases fast data may decide to go beyond the anticipated data area and return more entries than indicated by entry count, if additional space is available within the buffer.