Fetching data from subscription yields strange topic value

[auenbauer]

I was trying to use x$topic to identify which security belongs to the subscription output data but in some way the topic data look strange. Can you advice how to identify which security provides the given data?

code:

subscribe(securities=c("US0001W Index", "US0001M Index" ,"US0002M Index"),
          fields=c("BID"),
          fun=function(x) print(str(x$topic)))

part of the output:

NULL
 chr "Ð-�"
NULL
 chr "USSWAP3 Curncy"
NULL
 chr "USSWAP12 Curncy"
NULL
 chr "\\"
NULL
 chr "console"
NULL
 chr "I<—ƒ"
NULL
 chr "nNULL\\n chr \\\"°\\\\002Z\\\\b\\\"\\nNULL\\n ch\"| __truncated__\nNULL\n chr \"\"\nNULL\n chr \"°\\002Z\\b\"\nNULL\n chr \"| __truncated__
NULL
 chr ""
NULL
 chr ""
NULL
 chr ""
NULL
 chr ""
NULL
 chr "O<‘ƒe\031"

I am using Rblpapi version 0.3.6.

[meisterluk]

The data is retrieved at line 212 in subscribe.cpp. It seems like an invalid pointer dumping random data from userspace. @armstrtw has written that line in 2015. Maybe he can help?

[armstrtw]

looking at this. seems like bbg is returning a different topic id than those passed to it. hence, when dereferenced, it points to garbage.

additionally, is there a reason you are subscribing to non-ticking data? is the thought that you will get a notification when the days rate is posted?

[auenbauer]

I was using this three tickers for test purposes and the full list of tickers (see bellow) is for the USD money market and swap curve. I don't know what "non-ticking" means and thought this tickers would result in many updates during the day when I subscribe them and as a result I may want to get updates in intervals. My understanding was that this would "cost" less in terms of the data limit use compared to doing many updates via the reference method.

US0001W.Index,US0001M.Index,US0002M.Index,US0003M.Index,USSWF.Curncy,USSWI.Curncy,USSWJ.Curncy,USSWK.Curncy,USSWAP1.Curncy,USSWAP2.Curncy,USSWAP3.Curncy,USSWAP4.Curncy,USSWAP5.Curncy,USSWAP6.Curncy,USSWAP7.Curncy,USSWAP8.Curncy,USSWAP9.Curncy,USSWAP10.Curncy,USSWAP11.Curncy,USSWAP12.Curncy,USSWAP15.Curncy,USSWAP20.Curncy,USSWAP25.Curncy,USSWAP30.Curncy,USSWAP40.Curncy,USSWAP50.Curncy

[eddelbuettel]

I have the feeling that this may not help as an end run around data limits, but Bloomberg is famously opaque on what the limit is so nobody can know. Apart from them.

[johnlaing]

Swap rates (Curncy tickers) should return data as the market moves. However your first 4 tickers (Index) are not tradeable instruments. They are direct LIBOR rates and are fixed once daily rather than being determined continuously by the market.

An additional word of caution for these particular data: by default LIBOR rates on Bloomberg will be lagged. If you don't have entitlements for ICE you are likely getting yesterday's rates (or worse). In contrast, swaps should be realtime.

[auenbauer]

Thank you very much for this inside - I will replace the first four tickers then. 2018-01-21 2:48 GMT+01:00 John Laing <notifications@github.com>:

…

Swap rates (Curncy tickers) should return data as the market moves. However your first 4 tickers (Index) are not tradeable instruments. They are direct LIBOR rates and are fixed once daily rather than being determined continuously by the market. An additional word of caution for these particular data: by default LIBOR rates on Bloomberg will be lagged. If you don't have entitlements for ICE you are likely getting yesterday's rates (or worse). In contrast, swaps should be realtime. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#257 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOR8PQollH1MbL8Co31-pjV75z09Genrks5tMpd_gaJpZM4Rfh6n> .

[armstrtw]

pls test w/ current master.

[eddelbuettel]

Which is also in incoming/ at CRAN and awaiting processing to become the next release.

[meisterluk]

@auenbauer and me tried @armstrtw 's fix today after updating rblpapi using RStudio's builtin update manager.

R version 3.3.3 (2017-03-06) -- "Another Canoe"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-w64-mingw32/x64 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

> suppressPackageStartupMessages(library(Rblpapi))
> con <- blpConnect()
> subscribe(securities=c("US0001W Index", "US0001M Index" ,"US0002M Index",
"USS6M.Curncy"),
+           fields=c("BID"),
+           fun=function(x) print(str(x$data)))
List of 1
 $ reason:List of 4
  ..$ errorCode  : int 12
  ..$ description: chr "cannot obtain streamid"
  ..$ category   : chr "NOT_MONITORABLE"
  ..$ source     : chr " [nid:119]:bbdbm7"
NULL
List of 1
 $ reason:List of 4
  ..$ errorCode  : int 12
  ..$ description: chr "cannot obtain streamid"
  ..$ category   : chr "NOT_MONITORABLE"
  ..$ source     : chr " [nid:119]:bbdbm7"
NULL
List of 1
 $ reason:List of 4
  ..$ errorCode  : int 12
  ..$ description: chr "cannot obtain streamid"
  ..$ category   : chr "NOT_MONITORABLE"
  ..$ source     : chr " [nid:119]:bbdbm7"
NULL
List of 1
 $ reason:List of 4
  ..$ errorCode  : int 2
  ..$ description: chr "Invalid security, rcode = -1"
  ..$ category   : chr "BAD_SEC"
  ..$ source     : chr " [nid:119]:bbdbm7"
NULL

This shows that $data now raises an error showing that the security is invalid. At the same time $topic now gives the identities in a valid format (not shown here).

This fix works wonderful and thanks a lot to all involved people for the quick response. Thanks a lot to @armstrtw for the fix. Great job! We consider this issue closed.