Hi Salvatore, Thanks very much for the files here. Let me speak to our development teams to confirm what is happening here. In theory this shouldn't be happening in this way!

I will update you ASAP.

Hi Salvatore,

Can you confirm the RIC(s) you are seeing this with? And also is this for data internal to your organisation? OR is Reuters supplied data - Elektron or direct feed etc?

If it is internal data, then the most logical explanation is that the internal provider is setting the UpdateType to 0.

For Reuters data it could be that we are not receiving the update type indicator from the exchange etc so we cannot encode any other value for it.

The RIC(s) that I used are IBM, AAPL.O. Our company (ETrade) uses the Elektron feed for these requests . Also, I noticed that the updateType for trades have been properly set.

msgBase.msgClass: 4 <RSSL_MC_UPDATE>
msgBase.domainType: 6 <Market Price Message>
msgBase.containerType: 132 <Field List container type, used to represent content using fieldID - value pair data>
msgBase.streamId: 99
msgBase.msgKey.flags: 0
msgBase.msgKey.serviceId: 0
msgBase.msgKey.nameType: 0
msgBase.msgKey.name: <>
msgBase.msgKey.filter: 0
msgBase.msgKey.identifier: 0
msgBase.msgKey.attribContainerType: 0
msgBase.msgKey.encAttrib:
RsslUpdateMsg.flags: 144 <90>
RsslUpdateMsg.flags: Contains a sequence number
RsslUpdateMsg.flags: Payload information should not be conflated or aggregated.
RsslUpdateMsg.updateType: 2 <Update Event Trade>

IRGCOND ODD(32760)
SALTIM 13:58:10:000
SALTIM_MS 50290722
IRGPRC 160.342
IRGVOL 46
ACVOL_1 250117

Hi Salvatore,

I spoke a content specialist and he advised that this should be a rare occurrence. There were a few instances last year, but the Analysts addressed most of these. It would have to be something quite unusual as the feed logic should normally code the incoming message correctly.

I will pass on the details above to the content specialist so they can check further. It may be that you will need to open a Support Ticket with the Data Helpdesk so they can look into this in more detail - perhaps with more examples of dates and times when you have observed this issue.

Regards,
Umer

AAPL.O snapshot.zip

IBM.N ibmntxt.zip

Hi @salvatore.riccio sorry for not replying to this sooner. We have run this past the development team and also run some diagnostic tests and we cant see the same amount of "undefined" as you have in the sample files provided. We can trace updates all the way through our central infrastructure so this seems to be something local.

I am going to contact your account team to see if we can setup some diagnostic tests on your end to find out why there is a difference between your sample file and ours.

Thank you for help.

Hi Salvatore,

What version of UPA/ETA C++/Java are you testing with, and did the attached output come from the SDK subscriber example, or from a custom app?

I run a quick test on ETA 1.0.2 Java subscriber example and ETA 1.0.4 C++ va subscriber example, and see lots of quote update types as well as trade update types from AAPL.O), i.e. see quotes, and in this it differs from what you attach, this is why I ask.

Please keep in mind that update type attribute is not guaranteed to always be populated by the source with quote or trade type, or other defined type, it can come as undefined too, so an application should provision for that by looking at the set of fids received.

For reference only, including here update type def header

typedef enum{ 

RDM_UPD_EVENT_TYPE_UNSPECIFIED = 0, /*!< (0) Unspecified Update Event */ RDM_UPD_EVENT_TYPE_QUOTE = 1, /*!< (1) Update Event Quote */ RDM_UPD_EVENT_TYPE_TRADE = 2, /*!< (2) Update Event Trade */ RDM_UPD_EVENT_TYPE_NEWS_ALERT = 3, /*!< (3) Update Event News Alert */ RDM_UPD_EVENT_TYPE_VOLUME_ALERT = 4, /*!< (4) Update Event Volume Alert */ RDM_UPD_EVENT_TYPE_ORDER_INDICATION = 5, /*!< (5) Update Event Order Indication */ RDM_UPD_EVENT_TYPE_CLOSING_RUN = 6, /*!< (6) Update Event Closing Run */ RDM_UPD_EVENT_TYPE_CORRECTION = 7, /*!< (7) Update Event Correction */ RDM_UPD_EVENT_TYPE_MARKET_DIGEST = 8, /*!< (8) Update Event Market Digest */ RDM_UPD_EVENT_TYPE_QUOTES_TRADE = 9, /*!< (9) Update Event Quotes followed by a Trade */ RDM_UPD_EVENT_TYPE_MULTIPLE = 10, /*!< (10) Update Event with filtering and conflation applied */ RDM_UPD_EVENT_TYPE_VERIFY = 11, /*!< (11) Fields may have changed */ RDM_UPD_EVENT_TYPE_MAX_RESERVED = 127 /*!< (127) Maximum reserved update event type */} RDMUpdateEventTypes;

We've been investigating this in our labs. On a full tick Elektron Edge feed all the Trade and Quote messages are correctly tagged with the correct update type in that OMM attribute. Other exchange messages are tagged as Unspecified. For NYSE these are mostly LULD messages.

On an Elektron feed that is not full tick (eg Bandwidth Optimized Elektron or Elektron Connect) a lot of messages are tagged as Unspecified because they contain information conflated from multiple updates.

Please check what type of Elektron feed you are connecting to in your development environment.

I did some testing and used my program to connect directly to the Edge device. I found that the update type is populated 100% of the times w/ the proper Event type. Why can’t the ADH/ADS combo preserve the update type regardless of conflation, full tick … just like the trade messages or is this a configuration issue. If TREP knows it’s conflating QUOTES then why would it not preserve update type.

I did some testing and used my program to connect directly to the Edge device. I found that the update type is populated 100% of the times w/ the proper Event type. Why can’t the ADH/ADS combo preserve the update type regardless of conflation, full tick … just like the trade messages or is this a configuration issue. If TREP knows it’s conflating QUOTES then why would it not preserve update type.

Update, after viewing the updates more closely there are still some "Unspecified Update Event> types, but farless than coming from the ADS

@zoya.farberov

@Jonathan Haruni