[ts-gen] Do I really need to tail -f ShimText?

Ken Feng kfmfe04 at gmail.com
Mon Sep 14 08:25:31 EDT 2009


I am still working on how best to respond to upstream messages from
IB/TWS relayed through the shim.

Recall in the "Unique Identifier for Orders" thread, Bill quoted:

> By the way, here's what FutureScalper has just said on the Yahoo list
> about waiting for order feedback:

> > I guess it's mainly the orderStatus ... [message].  Well, you should
> > have some sort of state transition idea.  I mean, an order is alive
> > until it's cancelled or completely filled.  You can assume the API
> > will ... [send a message] ... for any significant state changes ...
> > in theory, anything could go wrong, but doesn't usually.

> > Usually you want to send command, check command success/failure if
> > applicable, and then await command confirmation.  If confirmation
> > doesn't come quickly enough which, for me would be a few seconds, then
> > consider the order to be in question.  You can abandon it, or somehow
> > try to figure out what's wrong with it, but that doesn't happen very
> > often.

> > If it's an attended system, then TWS can be a fallback to correct and
> > check position, etc.

This is exactly what I am focusing on.  I noticed that shim's stderr
gives some useful messages during the log-in process, but then doesn't
give much more information.  Most of the interesting order response
messages seems to go into ShimText.

Question:  If I need to know the moment that a response to an order is
coming from upstream, is the right approach to open a pipe to "tail -f
ShimText" and select() on that pipe?

If there is no better approach, that is exactly what I will do - check
for the 3/3/6 from that pipe and try to match it up with a row in the
OrderStatus table so I can get better processed details about what
just happened.

I can't help but feel that I'm doing something dirty/hacky by doing a
"tail -f ShimText" into Ruby.  Someone please tell me that I am wrong
and show me the light (ie a better way), before I fall into the
dark-side...  Thanks in advance.

I was hoping that Shim's stderr would show raw messages (like what's
in ShimText) while Shim's stdout would show "cooked" messages (nice
cooked stuff would also show up in MySQL as we see in the journal
tables)... ...oh, well...

- Ken
(In reality, it's not >THAT< bad, if I consider that I know all my
outstanding open orders, upon an order response from "tail -f
ShimText", I could query the OrderStatus table for those outstanding
open orders and update their latest statuses.  It ain't pretty, so
please show me a better way if you know of one...)

More information about the ts-general mailing list