IB improvements
- Thread starter Babak
- Start date
def
Sponsor
babak,
your suggestion of the short link on the front page got rejected. the reason is that one person wants this, the other wants that, etc. the idea is to to keep the front page as clutter free and clean as possible. I'd advise making a bookmark to the short page.
as for having a column or a flag on the TWS stating whether or not a stock can be shorted, i have not heard back yet. but i'm pushing.
as for a backup server... I'm really not sure what happened last week. by the time i arrived to work all was well and I have not spoken to anyone in the states about it. in any event, i do not think the problem would be solved byis simply moving from one server to another. for example, say a database gets corrupted. you just can't roll back to the old database if trading has already commenced. another example, say a piece of code gets implemented that causes unforseen problems. switching servers will not help if the same software was being run. these are just a few examples. the only positive spin i can put on this is that IB's reliability has been excellent. this was the first significant outage i can remember.
i'm a pragmatist and believe this is one of the costs of electronic trading. over the last year, a number of exchanges have had to halt trading due to sytem failures - london and australia to mention two. none of which are acceptable but they are consequences of electronic exchanges. The aim certainly is to create as many redunancies as possible but in the end there are so many things that can go wrong. Here are a few personal experiences:
The Hong Kong Stock Exchange was forced to halt twice over the past few years. The first was caused by a database failing when two similar orders being rec'd at the exact same instant by the exchange and the software didn't know how to process it.
The second time was when there was a power failure. Somehow an exchange employee pressed the wrong button which turned off the backup power.
In the end, the key is to learn from the errors and make sure they do not happen again. In the example above, I bet there is a piece of tape over the exchanges backup power switch now.
your suggestion of the short link on the front page got rejected. the reason is that one person wants this, the other wants that, etc. the idea is to to keep the front page as clutter free and clean as possible. I'd advise making a bookmark to the short page.
as for having a column or a flag on the TWS stating whether or not a stock can be shorted, i have not heard back yet. but i'm pushing.
as for a backup server... I'm really not sure what happened last week. by the time i arrived to work all was well and I have not spoken to anyone in the states about it. in any event, i do not think the problem would be solved byis simply moving from one server to another. for example, say a database gets corrupted. you just can't roll back to the old database if trading has already commenced. another example, say a piece of code gets implemented that causes unforseen problems. switching servers will not help if the same software was being run. these are just a few examples. the only positive spin i can put on this is that IB's reliability has been excellent. this was the first significant outage i can remember.
i'm a pragmatist and believe this is one of the costs of electronic trading. over the last year, a number of exchanges have had to halt trading due to sytem failures - london and australia to mention two. none of which are acceptable but they are consequences of electronic exchanges. The aim certainly is to create as many redunancies as possible but in the end there are so many things that can go wrong. Here are a few personal experiences:
The Hong Kong Stock Exchange was forced to halt twice over the past few years. The first was caused by a database failing when two similar orders being rec'd at the exact same instant by the exchange and the software didn't know how to process it.
The second time was when there was a power failure. Somehow an exchange employee pressed the wrong button which turned off the backup power.
In the end, the key is to learn from the errors and make sure they do not happen again. In the example above, I bet there is a piece of tape over the exchanges backup power switch now.
Improvement requests..
Sometimes it takes time but now I am 100% convinced IB does listen to this board and implements good ideas when they can. (thanks Def).
I know several members are asking a way to help automate IB.
One very simple suggestion would help a lot :
- export the execution log automatically each time there is an execution. (now we have to select the menu and file).
surely this is easy since IB has an execution window updated automatically. and other ascii log files maintained while IB is running (without asking for a file name etc..).
it could be optional with a flag setting.
Anything that helps automation is great. and that's one of them. It is a pity several IB users, including myself, had to look elsewhere for that (and found low commissions alternatives). However, I am attached to the straightforward IB system. it does what I want.
The Java TWS API is probably low priority but it is a pity. but I can understand, that's why I propose easier steps to help those who are ready to bite the bullet and live without an API, but please help us..
thanks
tntneo
Sometimes it takes time but now I am 100% convinced IB does listen to this board and implements good ideas when they can. (thanks Def).
I know several members are asking a way to help automate IB.
One very simple suggestion would help a lot :
- export the execution log automatically each time there is an execution. (now we have to select the menu and file).
surely this is easy since IB has an execution window updated automatically. and other ascii log files maintained while IB is running (without asking for a file name etc..).
it could be optional with a flag setting.
Anything that helps automation is great. and that's one of them. It is a pity several IB users, including myself, had to look elsewhere for that (and found low commissions alternatives). However, I am attached to the straightforward IB system. it does what I want.
The Java TWS API is probably low priority but it is a pity. but I can understand, that's why I propose easier steps to help those who are ready to bite the bullet and live without an API, but please help us..
thanks
tntneo
tnteo,
On exporting executions, I'd suggest making it an option on a menu. One of my IT specialties is designing efficient user interfaces and if there's one thing I've learned, it's to keep the OPTIONS open. Giving users the ability to customize rather than forcing certain behavior is always preferable. If developers add a feature, they should allow users to turn it on or off depending on their preference. I think IB has learned this from experience as I see the rollout of new features in this manner...ie., the arb meter and others can now be controlled with a check box.
On exporting executions, I'd suggest making it an option on a menu. One of my IT specialties is designing efficient user interfaces and if there's one thing I've learned, it's to keep the OPTIONS open. Giving users the ability to customize rather than forcing certain behavior is always preferable. If developers add a feature, they should allow users to turn it on or off depending on their preference. I think IB has learned this from experience as I see the rollout of new features in this manner...ie., the arb meter and others can now be controlled with a check box.
I would just like to second tntneo's request for an order entry api capability in TWS.
TWS already supports basket trading, where the trading commands are stored in an ASCII file. The format is very simple.
How about adding a port to TWS accepting the same commands from outside software. This would allow the API to be completely platform and operating system independent and require very little additonal testing.
TWS already supports basket trading, where the trading commands are stored in an ASCII file. The format is very simple.
How about adding a port to TWS accepting the same commands from outside software. This would allow the API to be completely platform and operating system independent and require very little additonal testing.
I would like to be able to enter OCA orders without the order ticket. It could be something like: Ctrl + leftclick to select the orders you want to combine. Then right click on one of them for the option "OCA" and click. Done. There would be no need to enter a name for the OCA; TWS can just give it a number or name by itself.
yes, I agree.
OCA orders easier to access. a new column maybe. Whatever does not require us to call the ticket dialog. Each time we call it we waste time. In the new beta the stop election and limit prices are now editable from the normal order line (without the dialog) I praise Def for fowarding this request from us and others.
This is exactly the kind of improvement we need. Something which saves time hundreds of times a year if not more.
I am a heavy user of OCA orders because they are server based automation. this means we have less automation to do on our side.
So I do not know what is the best way to do it, but the goal is clear, I trust the programmers to do their best.
tntneo
OCA orders easier to access. a new column maybe. Whatever does not require us to call the ticket dialog. Each time we call it we waste time. In the new beta the stop election and limit prices are now editable from the normal order line (without the dialog) I praise Def for fowarding this request from us and others.
This is exactly the kind of improvement we need. Something which saves time hundreds of times a year if not more.
I am a heavy user of OCA orders because they are server based automation. this means we have less automation to do on our side.
So I do not know what is the best way to do it, but the goal is clear, I trust the programmers to do their best.
tntneo
In addition it would be handy to be able to see in the order screen what orders have been combined as OCA. Could be the OCA name ("group" actually) visible in one of the fields. This could be the status field, or one of the beige fields on the left which are empty for order lines anyway. Or a new column. Or just some other kind of marking.
def
Sponsor
interesting how you guys are working on automating. writing executions to the disk was probably never considered as the I/O slow things down. not sure if this would work but have you considered leaving the execution window open and reading that. One other option that comes to mind and is a bit of a hack but the open position column could be read as well. I am not sure where/when easier API access stands on the priority list and i'll see if I can help with the writing of the execution log to the disk.
As for the OCA's I'll make this suggestion as well. Like the stop order limit charge, it may take a few releases to hit production if approved.
As for the OCA's I'll make this suggestion as well. Like the stop order limit charge, it may take a few releases to hit production if approved.
Hi Def,
We can not really read the information displayed on the screen, it's only graphics. Reading would require hacking the java code (which is possible of course but risky).
I/O are slower that ram, but nowadays machines are so fast that I believe it has no humanly measurable impact. Also, if the suggestion sees resistance, let's remember IB has a log file running for status information purposes. This would only be another log running. OK, OK, Def, I want it bad
Really, the execs and programmers should help us on the automation side, either all the way (Java API) or simple easy things which would put us on the way (OCA, Execution logs, basket orders -they don't accept stop orders so it is limited use for me, etc..). See, several are willing to ignore other platforms offering advanced and easy API. It's because IB has some advantages in automation, multiple accounts and now in a less extent commissions. And IB programmers help makes a great difference then. Tell them.
tntneo
We can not really read the information displayed on the screen, it's only graphics. Reading would require hacking the java code (which is possible of course but risky).
I/O are slower that ram, but nowadays machines are so fast that I believe it has no humanly measurable impact. Also, if the suggestion sees resistance, let's remember IB has a log file running for status information purposes. This would only be another log running. OK, OK, Def, I want it bad
Really, the execs and programmers should help us on the automation side, either all the way (Java API) or simple easy things which would put us on the way (OCA, Execution logs, basket orders -they don't accept stop orders so it is limited use for me, etc..). See, several are willing to ignore other platforms offering advanced and easy API. It's because IB has some advantages in automation, multiple accounts and now in a less extent commissions. And IB programmers help makes a great difference then. Tell them.
tntneo