I have a Non-Interactive Provider submitting live updates to our corporate RMDS infrastructure. These live updates are deltas and we rely on the ADH/ADS cache to supply the complete image when a consumer requests the instruments. This is fine but in some cases then the values exceed certain limits these values are not passed to the consumers in the initial image.
The RDM dictionary refines the MarketFeed type of the field as PRICE with size 17 and the RFW type as REAL64 with size 7. What are the limits of the values/exponents that can be placed into the REAL64 to have it successfully cached and overflow conditions can be detected and alerted/logged?
The RWF_LEN field in the RDMDictionary indicates the size of the field in caching. Be aware that throughout TREP 2.x series the symptoms of overflow have changed significantly, from ignoring, truncation and dropping the affected field in cache. Overflow is not recorded anywhere and UPA unfortunately does not contain any API for testing overflow.
For REAL fields consider 8-bits are used for exponent and the remainder for the fixed-point mantissa. Thus 7-byte field has a 6-byte mantissa of range from −(247) to 247 − 1.
ATS 1.4.1.E2 will truncate values, so publishing a BID of (9223372036854775807) will be truncated to (140737488355327).
In ADH/ADS 2.4.0.E2, if Real64 FID values do not fit in the RWF_LEN size defined by the dictionary, the values will be zeroed out. However, it won’t truncate or zero out the updates.
Note that the RWF_LEN sizes can be customized to cache the full field if desired, the provided values are only the minimums required for Elektron content.
The document FieldDictionary_Tool_24.pdf in ADH lists the cached significant digit sizes for appropriate lengths: