I'm using C++ API to subscribe for bond ticking data via refinitv platfrom.
Is there an object I can use to check on PRIMACT_TP ( 270 ) / SC_ACT_TP1 ( 280 ) without hardcoding values on my end ?
I'm looking for enumerator holding following values:
! ACRONYM FID
! ------- ---
! VALUE DISPLAY MEANING
! ----- ------- -------
0 " " undefined or unknown
1 " " trade price, no tick
2 #20DE# trade price, up tick or zero up tick
3 #20FE# trade price, down tick or zero down tick
4 " S" settlement price
5 "OB" first half of open range, bid price
6 "OA" first half of open range, ask price
7 "OT" first half of open range, trade price
8 "OH" first half of open range, high price
9 "OL" first half of open range, low price
10 "CB" first half of closing range, bid price
Hello @Umer Nalla,
The attached post explains how to implement the map from field id to all possible values on client side. I was expecting to enum/object from existing header file which will hold all possible values for specific fields according to the spec where it make sense of cause like in case of fields 270 / 280
The Data dictionary files - RDMFieldDictionary and enumtype.def - are updated several times a year - as and when values change, are added or deleted - independently of any API that uses them.
As such these values are considered data related and not API related.
Therefore, it is recommended that you should download the dictionary from the server you are connected to. The server you connect will be updated with the latest data dictionary files as and when they are changed.
One quick confirmation - you posted the question in the RFA forum - but I then you mention Refinitiv Data Platform - which is not supported by RFA?
Please confirm which API you are using - if you are using EMA C++ then you can use the following to get the Enum display value
case DataType::EnumEnum: fe.hasEnumDisplay() ? cout << fe.getEnumDisplay() << endl : cout << fe.getEnum() << endl;
Note that if are doing new development using C++, I would strongly urge you to use ElektronSDK - preferably Elektron Message API rather than RFA if possible.
RFA is our feature-complete API and ElektronSDK is our strategic API with longer-term support etc.
I fully agree with @Umer Nalla that downloading data dictionaries field and enum, from the infrastructure should be preferred to getting any dictionary, including enumerated values, from the local files.
A dictionary may and will eventually undergo enhancements, and by downloading them from the infra, the consumer is always up to date, in-synch with infra on parsing.
However, in case this will help,, in your RFA SDK, file-based dictionaries that were current at the point of time when SDK was issued, are kept in \etc\RDM folder and enumerated dictionary is called enumtype.def.
I am additionally attaching a zipped version that came with RFA JAVA 8.0, search for 270. is this what you are looking for?
Are we helpful on the explanation about using infra vs flle-based dictionaries?