What are valid PE ?
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 ?
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
Hello @vishakha.shailendra.singh
Do you still encounter the issue? If so, you can contact the support team via 09525319 case email loop directly.
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.
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.
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.
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.
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.
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.