What are valid PE ?

vishakha.shailendra.singh

What does the error line "FAILURE:BAD_PESET" denote when I query to Opendacs with a set of PE ? is it possible that Reuters publish an invalid PE. When I check the logs , the PROD_PERM published by reuters is 18446744073709551391. Does that mean it is not within the range of PE ?

wasin.w

Hello @vishakha.shailendra.singh

Do you still encounter the issue? If so, you can contact the support team via 09525319 case email loop directly.

umer.nalla

Hi @vishakha.shailendra.singh

Can you confirm the RIC you are extracting the PROD_PERM field from - the above value does not look right?

Is this a Refinitiv service (e.g. ELEKTRON_DD) or an internally published RIC within your organisation?

Please refer to the OpenDacs API pages - in particular the QuickStart and Tutorials to get a better understanding of what typical PE codes look like

Quick Start | Refinitiv Developers

Tutorials | Refinitiv Developers

You may also find the following overview on OpenDacs useful

An Introduction to the DACS Entitlement System for OpenDACS Developers | Refinitiv Developers

vishakha.shailendra.singh

RIC is /CFIVU.OQ and timestamp in GMT below with the value received from Reuters

2021-01-05 21:47:31,595 INFO reutersSubscriber [com.hsbc.dmds.services.rtp.plugins.reuters.ReutersRecordReceiver] - /CFIVU.OQ PROD_PERM=18446744073709551391

Its subscribed via RFAJ through service IDN_SELECTFEED.

It is directly taken from Reuters and no transformation is done at our end.

umer.nalla

Hi @vishakha.shailendra.singh

The above library you are using appears to be an internally developed wrapper - not pure RFA Java

If I subscribe to the same RIC using a standard RFA Java example, I see a PROD_PERM value of 5050

Please speak to the developer of the ReutersRecordReceiver plugin and ask them to confirm how they are populating the PROD_PERM field.

Also, check with the wrapper developer, if it allows you to enable low-level IPC tracing (a feature of the RFA Java API) then please enable the trace and check its output to confirm what value the underlying RFA Java transport is receiving from the server.

vishakha.shailendra.singh

That was just a one time event as per above timestamp . Even now I can subscribe to the same RIC using a standard RFA Java example, I see a PROD_PERM value of 5050 . As i mentioned earlier the wrapper is not doing any transformation and we were able to get all the other field data as is expected.

umer.nalla

Hi @vishakha.shailendra.singh

Apologies, I misunderstood the original post to mean that you were consistently getting the wrong PROD_PERM value and the 2nd post was just one example.

With regards to data quality issues, it is advisable to raise a Content-type ticket on My.Refintiv so that a content specialist can then investigate any particular occurrence of invalid data. Moderators on this forum are API specialist and therefore unable to investigate content issues.

On this occasion, I have raised a ticket on your behalf ref 09529009

Someone from the content team should hopefully contact you soon on the email address attached to your forum username.

zoya faberov

Hi all,

My understanding from the corresponding case details and resolution, that the issue was never replicated again and after a while under observation the case was closed.

vishakha.shailendra.singh

https://community.developers.refinitiv.com/discussion/comment/74171#Comment_74171

hello Reuters support did mention to have a check on the PE length which we have added to future proof our service from failing. This was just one occurrence and never happened again.