[ts-gen] How symbols and contracts are defined during database creation

[Bill Pippin]

Sam,

Your feedback below is much appreciated, and has allowed me to fix
what I believe to be the problem you were observing.  Please feel
free to download the newest release, and try it out.

> Here is the .req and .msg.

I quote below, from the trace info that you've submitted, the
request submitted by the shim as part of the contract info wild
card query script test that you've seen fail:
 
23|1|
 6| 2| 1||
 9| 3|AA|STK||1.00||1||||1|

In the trace above, there is the handshake for client version 23,
and client id 1; an account data request, in order to obtain the
account label; and a wildcard contract info request for STK:AA .

In the resulting messages below, we see the handshake; a next id
message; an informational [error] message about data farm
connectivity; one of many account data messages; a time check;
and, finally, an error message to the effect that the wildcard
contract info query unexpectedly has the empty set as its answer.

42|20080913 13:28:05 CET|
 9| 1|1|
 4| 2|-1|2104|Market data farm connection is OK:ibdemo|
 6| 2|AccountCode|DUxxxxx||DUxxxxx|
      ... more deleted ...
 8| 1|13:26|
 4| 2|-1|200|No security definition has been found for the request|

The key point for me, in diagnosis, is that the query request above
was exactly the same as what our local site produces, and yet our
query was working while the above example failed.  Given that I knew
that there was no difference in shim operation, this indicated variation
elsewhere, in particular the IB tws, and in fact I was able to reproduce
the problem with the 887.2 tws, whereas for earlier versions up through
886.5 the query worked just fine.

The tws versions differ as well in api server version, the earlier ones
reaching server version 40, while 887.2 jumps to server version 42.
Although each IB tws is supposed to be backwards compatible given a
consistent client version, in our case currently client version 23,
these versions are imperfectly defined, with the only reliable "spec"
being the example sample client code, which indicates the name,
number, order, and general type of request and message attributes, but
suggests only generally what the values should be, and in particular the
rules for dealing with null or default values.

Anyway, to make a long story short, in at least one case the api
requires a non-null default value for numeric attributes, 0.0 for the
strike price even when the contract is for a stock, while elsewhere it
accepts null strings for unknown or undefined attributes.  The problem
here with contract info queries lies with the contract multiplier; the
shim was printing a default value of 1, while the tws had been willing
to accept a null string here, and currently insists on it, presumably
because it now uses the value as part of the contract filter.  So this
newest release of the shim now uses a null string for the contract
multiplier in such queries.

Sam, thanks again for the bug report, and your patience in helping us
track down the problem.  I had been avoiding this newest version of
the IB tws for a number of reasons, not least problems that other
users seem to be having with it, but since the shim now has users
running it, your experience has led me to upgrade, and I've now
started developing against 887.2.

This is not meant to suggest that other users fortunate enough to have
one of the 886.x series installed should give it up; the shim should
work just fine with 886.x, and if not, please let me know.

Thanks,

Bill