We have encountered some exchanges which send a zero indicative to indicate a blank price but the isBlank field in the RsslReal struct is not being set true. This makes it difficult to determine whether a zero indicative price is a true 0 or a blank without having a manual hard-coded condition for each market to indicate that this specific market uses 0s to indicate blanks, whereas other markets use 0s to indicate actual 0s and set the isBlank field to indicate blank.
Some observed examples of this behaviour are:
XSAF: ALSI (JSE All Share Index)
XSFE: NBB (NZ bank bills), YAP (SPI200), YBA (Aus bank bills), YTC (Aus 10 year treasuries)
XTAF: TX (TAIEX)
Has anyone else observed this? It seems like a failure in data normalisation by refinitiv, however I had no luck getting a resolution through a support ticket.
Thanks!
1
●0 ●0 ●0
Receiving 0 indicative to indicate blank price but isBlank is not set
87k
●294 ●53 ●79
Thank you for reaching out to us.
I ran EMA C++ example (Cons120) to subcribe to /ABGJ.J.
Some fields contain real blank data.
How does the application check the blank data? The code should look like this:
void AppClient::decode( const FieldList& fl )
{
while (fl.forth()) {
cout << "Fid: " << fl.getEntry().getFieldId() << " Name: " << fl.getEntry().getName() << " value: " << fl.getEntry().getLoad().toString() << endl;
if (fl.getEntry().getLoad().getDataType() == DataType::RealEnum) {
if (fl.getEntry().getCode() == Data::BlankEnum) {
cout << "<### blank ###>" << endl;
}
}
}
}
Please share RICs and fields that the application received 0, as blank data.
You can also enable the XmlTraceToStdout and XmlTraceHex configurations to verify the raw data.
<Consumer>
<Name value="Consumer_1"/>
<Channel value="Channel_1"/>
<Logger value="Logger_1"/>
<Dictionary value="Dictionary_2"/>
<XmlTraceToStdout value="1"/>
<XmlTraceHex value ="1"/>
</Consumer>
@Jirapongse Thanks for your reply.
The FIDs we are looking at are IND_AUC and IND_AUCVOL.
Some exact RICs that we have observed this behaviour on are:
XSAF:ALSIU4 XSFE:NBBH5 XSFE:NBBH6 XSFE:NBBM5 XSFE:NBBM6 XSFE:NBBU4 XSFE:NBBU5 XSFE:NBBZ4 XSFE:NBBZ5 XSFE:YAPU4 XSFE:YAPV4 XSFE:YAPX4 XSFE:YBAH5 XSFE:YBAH6 XSFE:YBAM5 XSFE:YBAM6 XSFE:YBAU4 XSFE:YBAU5 XSFE:YBAZ4 XSFE:YBAZ5 XSFE:YTCU4 XTAF:TXQ4 XTAF:TXU4
We observe the behaviour daily between 7:16 am -7:17am UTC time.
As a specific example, on August 19th, for XSAF:ALSIU4, we received these messages:
07:16:01 Process update for stream 1263 instr XSAF:ALSIU4 07:16:01 Field 3912:IND_AUC processed from Statistics type REAL value 0 07:16:01 Field 3913:IND_AUCVOL processed from Statistics type REAL value 0
In this case, the exchange is known to use an IND_AUC value of 0 to indicate blank, however the refinitiv does not seem to be normalising the 0 it is sending to blank (it sends an actual indicative value of 0, which is not correct).
I do believe we are checking the isBlank field correctly, as it works as expected for many other symbols we trade.
Thanks!
87k
●294 ●53 ●79
Yes, I got the 0 value when subscribing to NBBM5.
As this forum is more for programming type queries, rather than content queries - I would recommend you raise a 'I need help understanding content within the product' ticket with our helpdesk. That way a Content specialist can work closely with you and verify the assumption.
@Jirapongse
Thanks for your reply.
Unfortunately I have been through the process of raising a ticket with the helpdesk, and the suggestion from them was to post on this forum.
Not sure if you have any other suggestions or avenues we could look at?
Regards,
Jeremy
@viv_manoj
I can submit a ticket on your behalf.
What data feed product (Real-Time Optimized, or Edge Device) are you using?
