Maybe one of the options practitioners can add a more definitive answer, but it looks to me as if your program is correct and that no Open tick #14 is sent for certain or all option contracts. That may be an issue with the IBKR feed or just something unique to instruments of secType OPT and FOP or the exchanges.

• BidPrice, AskPrice - a price of -1 when exchange is closed
• BidSize, AskSize, LastSize - a size of 0 when exchange is closed
• Close, MarkPrice - values that look like real/correct prices
• Halted , OptionCallOpenInterest, OptionPutOpenInterest, OptionImpliedVolatility
• and in some cases tickOptionComputation callbacks.

开云体育

On 22-10-2024 23:05, 闯ü谤驳别苍 Reinold via groups.io wrote:

What is most amazing to me is that API 972.03 has worked for you this long, Raoul. And proof that TWS API messages can really be understood by clients and TWS/IBGW that are years apart.

Looking back at all the changes, it is indeed surprising to see that things just kept running without any issues. I vaguely remember that in the past, tws would warn if the api version is no? longer supported or upgrade is strongly suggested. Some people on the mailinglist have seen this message pop up as well.

Eventually you should consider adopting a more modern API version, but I can see at least two scenarios that could buy you some time:

• It sounds like you had no problems with the most recent stable TWS/IBGW version 10.19.2p. If you still have an installer (or can get your hands on one) TWS 10.19.2p will probably be able to run for several more months before IBKR requires an update. In these cases it is always advantageous to run the "standalone" versions that do not automatically update.

That should probably work for a while, but I like how tws is running nicely with the auto update and all.

• I recently moved from TWS 10.19.2p to 10.30.1l myself (standalone versions) and I saw an option in the API Global Configuration that I had not noticed before. Is is called "Maintain connection upon receiving incorrectly formatted fields" and is disabled by default. Assuming your mismatch does not cause any functional issues, enabling this option may at least maintain the connection to TWS/IBGW

Nice suggestion you found there, but unfortunately it didn't prevent the disconnect (all my tws interactions are within try catch). The weird thing is that the order is placed correctly, which seems like the most critical part to me, but yet there's some other fatality.

I'll take the big jump to the current stable version instead and start reading through the (updated) manual.

But it sound like there is a "long weekend and several six packs" event coming up for you.

Oh I like those weekends, even more so with an api upgrade ;-)

As always, thanks again for your help 闯ü谤驳别苍!

Greetings,
Raoul

These are strong words, Marc, that really have no place here in our group.

From your last two posts it seems to me that there is a significant discrepancy between your expectations and what TWS API really is. I understand that is frustrating but it does not give you the right to dump your frustration onto our 6,000++ members.

I have put your account "on moderation" for now.

As we discussed in the topic "Is reqFundamentalData broken?" in June, reqFundamentalData() has been deprecated for a while now so that you had to be prepared for degraded service or termination at any time. I don't have the exact deprecation notice in front of me, but it was some time after TWS 10.10 when the Wall Street Horizon (WSH) data offerings became more complete and stable.

The TWS API documentation chapter "Fundamental Data" exclusively speaks about the WSH offerings and reqFundamentalData() has not been mentioned in a very long time.

And while IBKR support is in no way perfect, please keep in mind that they work within the scope that is clearly defined in the Introduction section of the TWS API documentation:

Our TWS API components are aimed at experienced professional developers ... . Before you use TWS API, please make sure you fully understand the concepts of OOP and other Computer Science Concepts. Regrettably, Interactive Brokers cannot offer any programming consulting.?

"Professional" is probably not required, but I do agree that experience specifically in message/event driven designs (or at least the willingness to learn) is essential. If that is not for you, clearly, TWS API is not for you either.

For most of us, TWS API has proven itself a high performance, extremely flexible, and very robust offering that can be adapted to any application architecture and virtually any programming language and style. And that for more than two decades.

What is most amazing to me is that API 972.03 has worked for you this long, Raoul. And proof that TWS API messages can really be understood by clients and TWS/IBGW that are years apart.

API 972.03 must be somewhere around API level 105, just shortly after the magic V100 level that made it possible for clients and TWS/IBGW to understand vastly different protocol levels.? API 10.30.1 is level 187 and has undergone more than 80 sometimes radical changes. Among them the chance from int to long for size fields, the subsequent change to a Decimal type, and the introduction of may new fields in Contract and Order objects.

• It sounds like you had no problems with the most recent stable TWS/IBGW version 10.19.2p. If you still have an installer (or can get your hands on one) TWS 10.19.2p will probably be able to run for several more months before IBKR requires an update. In these cases it is always advantageous to run the "standalone" versions that do not automatically update.
• I recently moved from TWS 10.19.2p to 10.30.1l myself (standalone versions) and I saw an option in the API Global Configuration that I had not noticed before. Is is called "Maintain connection upon receiving incorrectly formatted fields" and is disabled by default. Assuming your mismatch does not cause any functional issues, enabling this option may at least maintain the connection to TWS/IBGW

But it sound like there is a "long weekend and several six packs" event coming up for you.

开云体育

Hello,

Starting today, after placing an order I'm getting this strange error all of a sudden:

id=-1 errorCode=505 msg=Fatal Error: Unknown message id.

It comes back via the general error method??public void error(Exception e) in the implementation of EWrapper. Nothing has changed in the code, it's the same binary jar.

The order is placed correctly though, but after the error, tws disconnects.? From the 972 api doc, there does not seem to be an error code 505. And the more current documenation (IBKR Campus) this error says indeed Fatal Error: Unknown message id.

My TWS is on 10.30.1l of Aug 13 2024. My feeling is that the 972 api is just too old, but I may have missed something. I believe tws would show a warning when an certain api is getting outdated.

Is anyone else working succesfully with api 972.03 and tws 10.30.1l ?

Changing everything to api 1019.04 does have a big impact so it seems. It's not just a few parameters and types, but reqMktData and depth seem to work in a different way. The demo client app 1019.04 works fine, so I'll just have step through that I think.

Or is there an api version that does work, but with lower impact? So that I have more time to make the big jump to 1019.04 which will happen some day of course.

Thanks for any advice!

Greetings,
Raoul

开云体育