Migrating application from SSL to ETA; need data from FIELD_LIST_NO in IDN/MarketFeed

We're rewriting an application in ETA since SSL is end of life.

Part of the application logic examines the FIELD_LIST_NO field in the MarketFeed Header.

For example in Record_Response and Snap_Response (340), the record is defined as:

<FS>340<US>TAG<GS>RIC[<RS>R_STATUS]<US>FIELD_LIST_NO<US>RTL{<RS>FID<US>VALUE}<FS>

Some examples of data (using SSL) up to the beginning of the FID/VALUE section are:
<FS>340<US>XX<GS>AAPL.O<US>78<US>15728

<FS>340<US>XX<GS>BB.TO<US>74<US>1296

<FS>340<US>XX<GS>CGBU6m<US>38<US>24080

<FS>340<US>XX<GS>.DJI<US>77<US>3488

<FS>340<US>XX<GS>GOOG.O<US>78<US>20160

<FS>340<US>XX<GS>IBM.N<US>79<US>63344
<FS>340<US>XX<GS>.SPX<US>77<US>46080
<FS>340<US>XX<GS>TRI.N<US>79<US>21376

In these messages, the FIELD_LIST_NO has values of: 38, 74, 77, 78, and 79

The (apparently partial) list of meanings for these fields is:

static const int FieldList_ALL_FUTURES_B = 20;
static const int FieldList_NMTS_NBIDASK = 21;
static const int FieldList_MARKET_INDEX_A = 77;
static const int FieldList_LINK_A = 80;
static const int FieldList_PAGE_25X80 = 82;

static const int FieldList_SPREAD = 83;
static const int FieldList_LONGLINK = 85;

static const int FieldList_CM2000 = 89;

(Of the values seen in the data, the only one that we appear to have a definition or is 77)

In any case, our existing code appears to have particular affinity for types 80 and 85.

Is it possible to recreate this field by extracting one or more values from the various data structures and messages available using the ETA API?

Or did the original author write something using undocumented features of MarketFeed (resulting either some very magic or a bit of cruft -- or both)

Find more posts tagged with

elektron

ssl

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

market-feed

Accepted answers

Lars-at-Addicticks

The equivalent is the FIELD_LIST_NO which is a attribute of a FIELD_LIST.

In terms of ETA Java it would be something like:

fieldList.fieldListNum()

which returns an int, but is really - as far as I understand - a short. The equivalent method in RFA Java indeed returns a short. Well, well.

You can view the field list number by using TRexplorer.

In the screenshot below you can see an example:

The data item I'm displaying in the screenshot is an IDN Chain. Unsurprisingly it has a field list number of 85 (LONGLINK style chains).

Relying on field list numbers for anything but allocating memory seems to me to be a dangerous strategy so you may want to review why they are used by your application. However if you want to do a 1:1 migration then the above would be what you are looking for.

All comments

Lars-at-Addicticks

The equivalent is the FIELD_LIST_NO which is a attribute of a FIELD_LIST.

In terms of ETA Java it would be something like:

fieldList.fieldListNum()

which returns an int, but is really - as far as I understand - a short. The equivalent method in RFA Java indeed returns a short. Well, well.

You can view the field list number by using TRexplorer.

In the screenshot below you can see an example:

The data item I'm displaying in the screenshot is an IDN Chain. Unsurprisingly it has a field list number of 85 (LONGLINK style chains).

Joe.Ferraro

Thanks!!

It looks like its a field, not a method: (fieldList.fieldListNum), at least in the C API.

It also looks like it's only present when msgCLass is RSSL_MC_REFRESH or
RSSL_MC_UPDATE and updateType is RDM_UPD_EVENT_TYPE_VERIFY.

Just as it was in MarketFeed MsgTypes: 340 and 318

Now, I just have to figure out why they are using that data downstream.

Joe.Ferraro

Thanks!!

It looks like its a field, not a method: (fieldList.fieldListNum), at least in the C API.

It also looks like it's only present when msgClass is RSSL_MC_REFRESH or
RSSL_MC_UPDATE and updateType is RDM_UPD_EVENT_TYPE_VERIFY.

Just as it was in MarketFeed MsgTypes: 340 and 318

Now, I just have to figure out why they are using that data downstream.

Lars-at-Addicticks

Yes, it would only be present (only make sense) in those cases. However I'm under the impression that the API will always populate the field, so if it doesn't arrive on the wire it simply becomes 0. In other words : zero means "not defined".

Also: You would probably have to wait 10 years before you see an example where an open stream changes its fieldListNum in an UPDATE message of type VERIFY but I suppose it can theoretically happen. I would say it is a (almost) static value for the life time of the subscription.

EXPLORE OUR SITES