Yeah I've seen similar problems to that, not the same but similar... It makes it pretty difficult to run more than one bot per PC/account... - mnx
Maybe the regular way is if you use Sterlings Data. But if you use a third party Data then you will have to define the location of where the Data is coming from and some other things about the third party Data. So then you use the Structure (UDT) because it would take less messages to describe the location of the third party data.
I've got a question for you guys. Any suggestions on the fastest way to cancel a large number of orders, say in a panic situation? Manual or API would be fine. This morning I tried to manually cancel some bad OPG orders by filtering the bad orders in my order window, selecting all and hitting cxl selected. It took over 3 minutes for 1800 orders and not all the bad orders got cxl'd before the open!
This format choice applies only to order events. It does not apply to quote events. There is only one format for quote events.
I have hot keys setup for different type of cancellations, I would suggest looking into using that. But I assume most of your orders where placed at the NYSE Exchange? If so, they take longer for canceling than ECN's. That is why it is hard to automatically envelope near the inside quote, because NYSE cancels take a little longer and you can get filled when you don't want to on envelopes. Also ran into that problem when I tried to have pegging order types made for NYSE, the cancels took too long and by the time the order canceled and a new order was placed to the inside, the inside quote had already moved again.
That is very annoying. They should have API access to a function called "CancelAllOrders()", or maybe at least a method to pass an array of order IDs to let it be done more efficiently on their end. Of course when you right-click and try to cancel a lot of orders, they still queue up "sending"... moreso when the market picks up volume. It seems like it's about the same speed as cancelling a ton of orders through the API. I think it all goes back to the fact that things always seem to bog down on the server end when you need it the most, regardless of whos server you're running on. To me, that says either the overall architecture of Sterling sucks, or it just so happens that every firm that has their own servers are all overloading them. Qute a cooincidence, eh? At some point (ASAP as far as I'm concerned) these messages should be parsed into FIX and fired away lightning fast. I have no idea how orders are handled once they leave my machine, but it sure doesn't seem very efficient. EDIT: As a follow-up, it's not even that the orders take a long time to Cxl on the exchange end. Many times they are still "sending...". This should be instantaneous.
I don't see why the exchange would matter in my case. I want to mass cancel 1800 orders. I don't care how long it takes for NYSE to confirm, I just want Sterling to send cancels on all of them immediately. To be clear it wasn't the confirms that took 3 minutes. Rather, after 3 minutes there were still orders Sterling hadn't gotten around to sending the cancel for.
Unless I am reading this wrong it does apply to quote events? http://sterlingfinancialsystems.com/documents/Documentation/ActiveX_API_Guide.pdf