[ts-gen] order states

[Bill Pippin]

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