Hi Nigel,

I don’t have a RIC to quote here, but the problem exists for certain data delivered over the Elektron feed, with data from contributors where we have no control over what conventions they use.

For most data sets you only ever see blank values in initial data which is not really a problem. It’s when they are used to update a previously valid field value, distinguishing between a ‘blank’ and a zero (possibly valid) becomes important. The tick42rmds (or any other) adaptor can only really deliver a zero in the MAMA field it renders from the received ‘blank’ as there is no blank representation in MAMA and this is indistinguishable from a valid zero update, even though they are semantically different.

Regards,

Keith

Hi Keith – what we normally do here is use the relevant getters/setters on the Price and DateTime fields (getIsValidPrice, setIsValidPrice, HasDate, HasTime).  We tell people to render blanks for invalid prices and for DateTimes with no date or time part.  I believe the tick42rmds adaptor for TREP maps these correctly from the native TREP RWF encoding.  Do you have counter examples?

Certain other market data platforms / APIs (well, TREP) support the concept of ‘blank’ field values.

The price and time field types actually have special blank data representations defined.

This is used in the context where a publisher wants to include a field in a message but with no assigned value, possibly for example to indicate that a price that was previously offered and valid is now no longer available.

(Granted there are other ways to do this, with another price status field etc. but we do see this method used sometimes and with no other indicator of validity)

This introduces a conundrum when translating such values to the MAMA API as prices, times, etc. have no such equivalent blank representation in MAMA.

So, my proposal is that we might extend MAMA field data types to include such ‘blank’ values.

This would need to be done while preserving backwards-compatibility.

A discussion point for now

-  Is this a feature which others see value in?

-  Any feasible suggestions for how it might be achieved and what values would be used for ‘blank’ ?

Regards,

Keith

---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.

---
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

Please refer to https://www.db.com/disclosures for additional EU corporate and regulatory disclosures and to http://www.db.com/unitedkingdom/content/privacy.htm for information about privacy.

This message is confidential and subject to terms at: https://www.jpmorgan.com/emaildisclaimer including on confidential, privileged or legal entity information, viruses and monitoring of electronic messages. If you are not the intended recipient, please delete this message and notify the sender immediately. Any unauthorized use is strictly prohibited.