Hello @stefan.lechner

Regarding “my java application get's only 3 decimal places while the legacy app delivers 6 decimal places for the same RIC.”, I found the opposite results from the example application shipped with RFA7.6(MarketData interfaces) and RFA8(OMM interfaces) as shown below:

The example data of RIC IBM.N from MDSubDemo using MarketData(MD) interfaces:

The example data of RIC IBM.N from StarterConsumer using OMM interfaces:

You can see that OMM interfaces gets 6 decimal places while MarketData interfaces gets 2 decimal places. This was caused from MDSubDemo did not apply the hint specifying the number of decimal places for this field so all zero(s) after decimal were truncated. However, StarterConsumer uses com.reuters.rfa.omm.OMMData.toString() to print data.

You should try StarterConsumer to check if the number of decimal is less than your legacy application. The application is in

<RFA package>\Examples\com\reuters\rfa\example\omm\cons

The example command line to subscribe RIC IBM.N from the service named ELEKTRON and run 5 minutes:

java  -cp ..\Libs\rfa.jar;..\Examples com.reuters.rfa.example.omm.cons.StarterConsumer -session myNamespace::consSession -user pimchaya -itemName IBM.N -serviceName ELEKTRON -attribInfoInUpdates true -enumType ..\etc\RDM\enumtype.def -rdmFieldDictionary ..\etc\RDM\RDMFieldDictionary -runTime 300

Please refer to package.html in the application folder for each parameter of the application.

How do you know it is actually different on the wire and that is is not just something your application does?

In any case, in the following I'll assume you mean a difference in significant decimals.

You are not - incidentally - converting the price to a native floating point type are you? (i.e. type 'float' or 'double' in Java). I guess you can sense from my phrasing what I feel about floating point types. They are bad for your health and you almost never need them. :-)

Dealing with market data is almost always about either displaying data or transporting them to some other system. Perhaps your application may even compare prices. But do heavy algorithmic on them? I doubt it. For this reason, I believe floating point types (because of their unpredictability) should be avoided 99% of the cases when dealing with market data. Don't even get me started on blank values which cannot be expressed in native types.

Okay, moving on. Rant stops here. I don't know if use of floating point types is your case or not.

The important thing here is the wire format. I don't know what your legacy application is, but let's assume that it is consuming MarketFeed at the wire level?. In contrast an application made with the more modern APIs consume RWF (Reuters Wire Format) at the wire level. MarketFeed is a text-based protocol. So a price of 123.45 travels the wire as "123.45". RWF is a binary protocol. Here a price travels the wire as a integer value (12345) and a scale (2) which is a lot more compact way of expressing the same thing. At the extreme margins there are differences between what price values can be expressed in MarketFeed vs RWF, but a difference of 3 vs 6 decimals sounds to me like a difference in how the two applications treat the value (or presents it) rather than how it arrives to the application, i.e. how it is sent from the server.

From my experience there has never been a Thomson Reuters API where precision would somehow be lost within the client library itself, assuming of course you use the right methods from the API. There's always a method that will give you the full precision. For example in RFA Java the OMMNumeric.toBigDecimal() method doesn't loose any precision. Also the OMMNumeric.toString() method should be fine.

Hope this help.

Thanks for all the hints.

Regarding OMM and RFA I did everything right, BigDecimal not Float no rounding, but at the end, when writing a file with the ask/bid values, I used a NumberFormat.getInstance(locale) to format it according the customers need.

Using my developer account for testing, I used indeed only RICs with 2 or 3 decimal places.

I even debugged the OMM Messages, to be sure that I'm not shortening something.

But I never figured out, that the default NumberFormat has a MaximumFractionDigits of 3, which caused my problems.

@Pimchaya.Wongrukun:

Thanks for the hint with the OMM Cons demo, this showed me that I'll get more decimal places if there are any.