[ts-gen] Unique Identifier for Orders
kfmfe04 at gmail.com
Sat Sep 12 07:53:11 EDT 2009
Thank you for that detailed explanation.
> As for a risk mode connection with connection id of 4, you should leave
> the client id values from 1--7 for the use of data-mode clients. You'll
> find that 8 is the default for risk mode, and otherwise you may set the
> ClientId variable to whatever larger non-zero counting number you wish.
> If you must use zero, be aware that such use is not supported, and that
> there are known problems due to the IB tws gui's habit of confiscating
> order ids from the connection-zero number space for its own use.
My client id selection was unintentional. I will delete ClientID from
my .shimrc to get an automatic allocation. Thx.
Now, focusing on the CreateEvent table, I realize that 'var' is the
key I want to use.
> create table CreateEvent
> uid int unsigned not null auto_increment primary key,
> var varchar(96) not null, unique key(var),
> acc int unsigned not null references AccountCode(uid),
> client_id int unsigned not null,
> order_tag int unsigned not null,
However, as reponses come from upstream, I want to capture important
events in real-time either by parsing the raw pipe, or preferably,
looking up the already parsed values in Shim's tables.
So let's pick some very specific examples.
Looking at the raw stderr output, I see that 3/3/6 is used for
Submitted, ApiCancelled, and Filled.
Naturally, I would like to find out which order has been Submitted or
ApiCancelled, and I would like to find out about the Fill prices and
1420|35248| 0.000104|3| 3|
13112|10457| 0.000052|3| 3|
9490|01556| 0.000101|3| 3| 6|56|ApiCancelled|0|50000|0.000000|0|0|0.000000|8|
So I am trying to parse these three rows and somehow join enough
tables to get back to CreateEvent.var. I understand and totally
accept that when SENDING creates, updates, etc... upstream, I can
easily do it through my own designated CreateEvent.var.
However, the problem I'm having is in the other direction. When there
are responses like the three lines above from upstream, I am having a
hard time mapping this information back to CreateEvent.var in
real-time. I need things like confirmed cancels and submissions and
detailed fill information so I can pass them into the signal
calculator to generate new signals.
Am I taking the wrong approach? Specifically, what is the best way to
handle those three rows above? Assume that I just received those rows
into my Ruby script and I want to somehow map them back into
CreateEvent.var. If possible, I would like to parse those three rows
just enough for me to look up your parsed rows in Shim's database!
The answer may be staring me in the face, but it's not so obvious at
the moment. I will reread your explanation, dig into the database
more, and see if I can figure out the answer.
It's too bad that IB/TWS doesn't seem to carry some kind of identifier
along from the original order as a response.
More information about the ts-general