Topics

Adding Blank data representation to MAMA API data types


Keith Rudd
 

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.


Phelan, Nigel
 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.


Keith Rudd
 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.


Phelan, Nigel
 

Still not sure I see the problem, Keith.  If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call setIsValidPrice() to mark the field as containing an “invalid” price and the consuming client should honour this and display it as a blank (in exactly the same way you would if someone decided to publish “NOT QUOTING” in a bid/ask price field because the underlying middleware allowed free text entries there).  That’s why I was looking for an example of when this breaks.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Keith Rudd [mailto:keith.rudd@...]
Sent: 10 December 2019 11:47
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.


Keith Rudd
 

Thanks Nigel – I am with you now.

Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be updated to do that.

This only covers the price field case as there do not appear to be any equivalents methods for other field types, like times or integers, but perhaps this will be enough to cover the most important case.

Will refer back to our users for more analysis to see if using this is enough.

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 10 December 2019 12:19
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

Still not sure I see the problem, Keith.  If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call setIsValidPrice() to mark the field as containing an “invalid” price and the consuming client should honour this and display it as a blank (in exactly the same way you would if someone decided to publish “NOT QUOTING” in a bid/ask price field because the underlying middleware allowed free text entries there).  That’s why I was looking for an example of when this breaks.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Keith Rudd [mailto:keith.rudd@...]
Sent: 10 December 2019 11:47
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.



---
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.


Phelan, Nigel
 

For integers, yes, I agree.  For dateTimes, as I said, you can indicate if the date part is valid or the time part is valid (hasDate()/hasTime()/setHints()).  If neither flag is set, we interpret that as an invalid dateTime and tell people to render as a blank.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 10 December 2019 16:35
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

Thanks Nigel – I am with you now.

Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be updated to do that.

This only covers the price field case as there do not appear to be any equivalents methods for other field types, like times or integers, but perhaps this will be enough to cover the most important case.

Will refer back to our users for more analysis to see if using this is enough.

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 10 December 2019 12:19
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

Still not sure I see the problem, Keith.  If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call setIsValidPrice() to mark the field as containing an “invalid” price and the consuming client should honour this and display it as a blank (in exactly the same way you would if someone decided to publish “NOT QUOTING” in a bid/ask price field because the underlying middleware allowed free text entries there).  That’s why I was looking for an example of when this breaks.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Keith Rudd [mailto:keith.rudd@...]
Sent: 10 December 2019 11:47
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.



---
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.


Frank Quinn
 

For the record, I’m not opposed to a “first class” null data type in principle. Json and msgpack for example have it fine. It does raise a bit of ambiguity though on how to handle a NULL value in terms of caching and data type safety. I think we would need to make it clear that a NULL value is indicative of a “this field no longer has a valid value” scenario rather than “this field has not been updated” when being applied to any caches.

 

I think the cleanest way to do this is something like

 

mamaMsgField result;

mamaMsg_getField(msg, name, fid, &result);

mama_bool_t isNull = mamaMsgField_isNull(field); // <-- New Method

 

That way we could apply across all fields without having to have separate implementations per data type. That would then expose a similar bridge method to handle that. This is opposed to actually mapping the null type to a proper mamaMsg_getNull() type approach which I think would be abrasive for most OpenMAMA developers who are using strongly typed languages.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Phelan, Nigel via Lists.Openmama.Org
Sent: 10 December 2019 17:34
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Cc: Openmama-dev@...
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

For integers, yes, I agree.  For dateTimes, as I said, you can indicate if the date part is valid or the time part is valid (hasDate()/hasTime()/setHints()).  If neither flag is set, we interpret that as an invalid dateTime and tell people to render as a blank.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 10 December 2019 16:35
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

Thanks Nigel – I am with you now.

Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be updated to do that.

This only covers the price field case as there do not appear to be any equivalents methods for other field types, like times or integers, but perhaps this will be enough to cover the most important case.

Will refer back to our users for more analysis to see if using this is enough.

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 10 December 2019 12:19
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

Still not sure I see the problem, Keith.  If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call setIsValidPrice() to mark the field as containing an “invalid” price and the consuming client should honour this and display it as a blank (in exactly the same way you would if someone decided to publish “NOT QUOTING” in a bid/ask price field because the underlying middleware allowed free text entries there).  That’s why I was looking for an example of when this breaks.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Keith Rudd [mailto:keith.rudd@...]
Sent: 10 December 2019 11:47
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.



---
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.


Phelan, Nigel
 

I’d be cautious about that one, Frank – you’d need to think about the implications for the payload bridges because you’d need valid representations for NULL for all field types (or possibly you’d need a new “null field” type and numerous tweaks to handle the possibility that any field could contain content of the type specified in the dictionary or a null field representation).  I’d probably wait until the problem was better defined before proposing an implementation.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 11 December 2019 07:48
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

For the record, I’m not opposed to a “first class” null data type in principle. Json and msgpack for example have it fine. It does raise a bit of ambiguity though on how to handle a NULL value in terms of caching and data type safety. I think we would need to make it clear that a NULL value is indicative of a “this field no longer has a valid value” scenario rather than “this field has not been updated” when being applied to any caches.

 

I think the cleanest way to do this is something like

 

mamaMsgField result;

mamaMsg_getField(msg, name, fid, &result);

mama_bool_t isNull = mamaMsgField_isNull(field); // <-- New Method

 

That way we could apply across all fields without having to have separate implementations per data type. That would then expose a similar bridge method to handle that. This is opposed to actually mapping the null type to a proper mamaMsg_getNull() type approach which I think would be abrasive for most OpenMAMA developers who are using strongly typed languages.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Phelan, Nigel via Lists.Openmama.Org
Sent: 10 December 2019 17:34
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Cc: Openmama-dev@...
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

For integers, yes, I agree.  For dateTimes, as I said, you can indicate if the date part is valid or the time part is valid (hasDate()/hasTime()/setHints()).  If neither flag is set, we interpret that as an invalid dateTime and tell people to render as a blank.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 10 December 2019 16:35
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

Thanks Nigel – I am with you now.

Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be updated to do that.

This only covers the price field case as there do not appear to be any equivalents methods for other field types, like times or integers, but perhaps this will be enough to cover the most important case.

Will refer back to our users for more analysis to see if using this is enough.

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 10 December 2019 12:19
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

Still not sure I see the problem, Keith.  If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call setIsValidPrice() to mark the field as containing an “invalid” price and the consuming client should honour this and display it as a blank (in exactly the same way you would if someone decided to publish “NOT QUOTING” in a bid/ask price field because the underlying middleware allowed free text entries there).  That’s why I was looking for an example of when this breaks.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Keith Rudd [mailto:keith.rudd@...]
Sent: 10 December 2019 11:47
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.



---
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 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.


Frank Quinn
 

Yes that’s why I was suggesting this approach – it’s backwards compatible with existing bridges (we can make the bridge methods optional now where no implementation exists) and it doesn’t require adding a new MAMA field type (since it’s a special case here common to all existing field types which the payload bridge may optionally handle).

 

The interface could be modified to suit of course but just wanted to raise a proposed solution which won’t involve having to do all the fun we currently have with trying to parse a date / price several different ways (string, datetime etc) to try and make this fit.

 

But you’re right I’ll await further definition…

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Phelan, Nigel <nigel.phelan@...>
Sent: 11 December 2019 09:02
To: Frank Quinn <fquinn@...>; Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

I’d be cautious about that one, Frank – you’d need to think about the implications for the payload bridges because you’d need valid representations for NULL for all field types (or possibly you’d need a new “null field” type and numerous tweaks to handle the possibility that any field could contain content of the type specified in the dictionary or a null field representation).  I’d probably wait until the problem was better defined before proposing an implementation.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Frank Quinn [mailto:fquinn@...]
Sent: 11 December 2019 07:48
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

For the record, I’m not opposed to a “first class” null data type in principle. Json and msgpack for example have it fine. It does raise a bit of ambiguity though on how to handle a NULL value in terms of caching and data type safety. I think we would need to make it clear that a NULL value is indicative of a “this field no longer has a valid value” scenario rather than “this field has not been updated” when being applied to any caches.

 

I think the cleanest way to do this is something like

 

mamaMsgField result;

mamaMsg_getField(msg, name, fid, &result);

mama_bool_t isNull = mamaMsgField_isNull(field); // <-- New Method

 

That way we could apply across all fields without having to have separate implementations per data type. That would then expose a similar bridge method to handle that. This is opposed to actually mapping the null type to a proper mamaMsg_getNull() type approach which I think would be abrasive for most OpenMAMA developers who are using strongly typed languages.

 

Cheers,

Frank

 

Frank Quinn, Cascadium | +44 (0) 28 8678 8015 | http://cascadium.io

 

From: Openmama-dev@... <Openmama-dev@...> On Behalf Of Phelan, Nigel via Lists.Openmama.Org
Sent: 10 December 2019 17:34
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Cc: Openmama-dev@...
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

For integers, yes, I agree.  For dateTimes, as I said, you can indicate if the date part is valid or the time part is valid (hasDate()/hasTime()/setHints()).  If neither flag is set, we interpret that as an invalid dateTime and tell people to render as a blank.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 10 December 2019 16:35
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: Re: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

Thanks Nigel – I am with you now.

Was not aware of the ‘setIsValidPrice()’ method. Our version of the tick42rmds bridge does not use it when translating messages received, but it could be updated to do that.

This only covers the price field case as there do not appear to be any equivalents methods for other field types, like times or integers, but perhaps this will be enough to cover the most important case.

Will refer back to our users for more analysis to see if using this is enough.

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 10 December 2019 12:19
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

Still not sure I see the problem, Keith.  If you receive the data as a string field and, when the transport bridge tries to map it to a mamaPrice field, the conversion fails, you should call setIsValidPrice() to mark the field as containing an “invalid” price and the consuming client should honour this and display it as a blank (in exactly the same way you would if someone decided to publish “NOT QUOTING” in a bid/ask price field because the underlying middleware allowed free text entries there).  That’s why I was looking for an example of when this breaks.

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Keith Rudd [mailto:keith.rudd@...]
Sent: 10 December 2019 11:47
To: Phelan, Nigel (CIB Tech, GBR) <nigel.phelan@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

 

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

 

 

From: Phelan, Nigel [mailto:nigel.phelan@...]
Sent: 09 December 2019 17:03
To: Keith Rudd <keith.rudd@...>; 'openmama-dev@...' <openmama-dev@...>
Subject: RE: Adding Blank data representation to MAMA API data types

 

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?

 

Nigel

 


Nigel Phelan | Corporate & Investment Bank | Market Data Services | J.P. Morgan

 

From: Openmama-dev@... [mailto:Openmama-dev@...] On Behalf Of Keith Rudd
Sent: 09 December 2019 16:49
To: 'openmama-dev@...' <openmama-dev@...>
Subject: [Openmama-dev] Adding Blank data representation to MAMA API data types

 

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.



---
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 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.