[ts-gen] order states

[Ken Feng]

I got a batch of six "ApiPending" messages from the upstream today.
It happened while I was away, but these trades are no longer in TWS,  
when I checked later.

It looks like IB is trying to be creative...

- Ken

On Oct 8, 2009, at 4:42 AM, Bill Pippin wrote:

> Ken,
>
> There are a number of points for me to respond to here, and I'll
> take them in turn:
>
> About seeing PendingSubmit in order status messages:
>
>> I have definitely seen PreSubmitted and PendingSubmit ...
>> It's not frequent, but here is one that I saw:
>
>> ... 0.000039|3| 3| 6|1292|PendingSubmit|100000|350000|0.899400|...
>
> Well, that's pretty definite; thinking back, I may have seen these
> myself as well, or else Nils mentioned them.  It's clear that the
> IB APIguide.pdf documentation is misleading or confusing on this
> point.
>
> Now, the key point, about lost posts:
>
>> ... but [it] didn't make it into the Journals - I think your fix
>> will take care of this.
>
> Maybe not.  This is probably some other problem for OrderStatus
> posts.  Note, from the create table statement excerpt below, that
> the order status is part of the key declarations:
>
>>  unique key(acc, perm,                 status, filled, remaining),
>>  unique key(acc, client_id, order_tag, status, filled, remaining),
>
> So, although you could conceivably have lost posts with duplicate
> keys due to repeating order_tag (order id) values, which problem has
> been fixed, at least the first would remain in the database.  If you
> can't find any instances for PendingSubmit, something is wrong.
>
> Since this is an intermittent problem, let me say here to both you,
> Ken, and Nils, and for that matter any other users reading the list,
> please help me find a reproducing test case.  Post to the list if you
> see mysql error dumps for the insert, since the shim lists those;
> post to the list if you see syntax errors for the order status
> message read, or mapping therefrom to the OrderStatus record, since
> the shim lists problems in either case; and use the "warn" option so
> you know if duplicate keys or other insert statement warnings are
> a problem, since the warn option will tell the shim to list those
> issues as well.
>
> By the way, if I may note what should be obvious: for the distinct
> and separate problem of order status messages that are expected, but
> don't arrive in the log --- the report above is about logged events
> that don't reach the database OrderStatus table --- users should
> ensure they have a continuous, uninterrupted shim session, and
> consider providing reasonable delays, say 0.3 seconds, from one
> order command to the next.
>
> I've mentioned this before: order status messages are actually
> events, and if the shim is not running so it can detect their
> occurrence, they won't, by their nature, be received.  And if the
> concurrent threads of the IB tws are in conflict due to known
> races with their upstream, the order status event may not even
> be produced.
>
> Now, about commission information:
>
>>> ... newest version of the open order message includes commission
>>> information, which may be of interest to some users.
>
>> Yes!  I would be interested in that commission information ...
>
> Providing such information waits for our work on versioning, next on
> our roadmap after memory, the current major task.
>
> Thanks,
>
> Bill
>
> _______________________________________________
> ts-general mailing list
> ts-general at trading-shim.org
> http://www.trading-shim.org/mailman/listinfo/ts-general