开云体育

I have seen this suggested by several different people but I have always been skeptical.

If I submit an order at 9am that passes margin checks and then proceed to loose 90% of my account by noon, I can't bring myself to believe that IB will allow the now non-compliant order to fill when I change it. In other words I believe there has to be some validation at execution time, not just submit time.

It may be that modifying an order has less overhead than submitting a new order but I can't believe that IB would expose itself to changes in a client's risk profile that happened after the order was submitted.

Ben, this is great. I don't understand Java so I appreciate the "answer" that there isn't much that can be done since the source is closed and the traditional "command line" memory parameters are becoming deprecated, meaning garbage collection is essentially out of my hands. I also appreciate the "modify order" tip- that is very, very cool. My own trading tool is compiled C++ and is very fast, and the IB market data "feed" such as it is is almost certainly the biggest source of latency, especially with your tip for the credit workaround.

Ah, that's very interesting! ?I'm on Mac OS X so it seems I can't use the Linux utilities you are referring to.

Ben, thanks for pointing out. The comments you referred to seem to interchangeably refer to TWS and IBGateway. Is it possible to somehow run the same download "as" IBGateway, or are you just talking about both at the same time? Or do you actually mean IBGateway, most of the time, when you refer to TWS?

Thanks, it was indeed that simple.

It could be spelling.? This is from the API docs:
whatToShow String
Determines the nature of data being extracted. Valid values include:

• TRADES
• MIDPOINT
• BID
• ASK
• BID_ASK
• HISTORICAL_VOLATILITY
• OPTION_IMPLIED_VOLATILITY

At 07:37 AM 12/5/2015, you wrote:

...seems to be gone. I kept checking the download page for a standalone version of IB Gateway (Mac OS X) that would correspond to TWS "latest" version 954.2 (or newer), but there was only an older one from March 2015.

FWIW:

?

I have enjoyed this sort of thing "forever" -- even back to The Journal Of Mathematical Psychology -- which was the vehicle by which Kahneman, Tversky, et.al. got their stuff published in the early/mid 80s. Finding such an official-sounding word like "Quorum sensing" re-assures me that, if I won The Lottery and funded my own fun-for-thinking Institution, "Quorum sensing" might be in the title. (Or at least on somebody's door, right?)

In the meantime, you can bet your bippy that those who sample word-flow from Twitter, StockTwits, etc. have just these sorts of frameworks in place. (I want my own! Ha-HA!)

No, you don’t need to use the expiry field.



It works just fine with secType=”FUT”, exchange=”ECBOT”, and localSymbol=”ZB DEC 15”.



The only difficulty is that different exchanges have different local symbol formats. For Globex, Nymex and many other futures exchanges the ‘short’ format that you’ve always used (eg CLF6, ESZ5, 6EH6) is correct, but for ECBOT, DTB (and possibly others) the SSSS MMM YY format is required, eg ZC DEC 16, FDAX DEC 15.



The trick with this ‘long’ format is to ensure that there are 5 characters before the first month character, padding with spaces if need be. So for a two character symbol like ZC, you need three spaces after it, for a four character symbol like FDAX you need one space after it.



What’s even trickier is that what you put in the SSSS part is not necessarily the plain symbol. For example, the Euro STOXX50 contracts at DTB have a symbol of ESTX50, but in the local symbol you have to use FESX, thus ESTX50 with an expiry date of 201512 has a local symbol of FESX DEC 15. Simlarly for DAX you use FDAX in the local symbol (eg FDAC DEC 15), and for GBL you use FGBL (eg FGBL DEC 15).



Simple, huh?...



By the way, the long format is arguably much more logical, because it’s immune to changes of decade. For example I have historical data stored back to 2003, so I need contract definitions in my database for the ESZ5 in both 2005 and 2015. But I use the local name as a key to access the data, so I’ve had to change all the old ones to put the decade in as part of the local symbol: thus the ESZ5 for Dec 2005 is now called ESZ05 in my database. Whereas FDAX DEC 05 and FDAX DEC 15 are perfectly clear (I probably won’t care when we wrap round to the next century!).



Richard





From: TWSAPI@... [mailto:TWSAPI@...]
Sent: 03 December 2015 02:02
To: TWSAPI@...
Subject: Re: [TWS API] Re: ECBOT historical data





Thanks to those who responded. I have it working now.



To summarize, the trick for the ECBOT contracts is to specify the expiry in the Contracts object. For stocks, forex and all other futures, I have never used this field. I have left it "" and I have always used just the localSymbol field, e.g. CLF6. For some reason IB chose to make the localSymbol difficult for this exchange as one of the responders pointed out.



I have watched this forum for a long time and am amazed that I am the only one who has had this problem. I guess when everyone else started programming this interface that they started using the expiry field at the outset.



Phil







On Wednesday, December 2, 2015 12:48 PM, "fantasy football fantasyfootball672@... [TWSAPI]" <TWSAPI@...> wrote:





Phil,



It's a very annoying system for the "Local Symbol" with 3 embedded spaces:



For instance, Corn for December is: "ZC DEC 15"















[Non-text portions of this message have been removed]