See tag59 (Eg, http://www.onixs.biz/tools/fixdictionary/4.4/tagNum_59.html).
On Apr 20, 12:52 am, 'General Q/A' forum at fixprotocol.org <[email protected]> wrote: > [This message was posted by Hanno Klein of Deutsche Börse Systems > <[email protected]> to the "General Q/A" discussion forum > athttp://fixprotocol.org/discuss/22. You can reply to it on-line > athttp://fixprotocol.org/discuss/read/248cc7c3- PLEASE DO NOT REPLY BY MAIL.] > > ExecInst is the right place on the order level. I wanted to add that we plan > to submit a proposal for the session level along the same lines, i.e. > SessionInst as opposed to ExecInst. The idea is to have the ability to > express an event (connection loss, trading halt, system failure) a type > (cancellation or suspension) and a scope (orders (all or only non-persistent > orders), quotes). > > Bilateral agreement then governs which of the abilities is actually being > offered. > > Regards, > Hanno. > > > > > That's what I was looking for. I must have overlooked it in the spec. > > Thanks John! > > > > Hi Dmitry, > > > > I agree that this is often implemented (upon bilateral agreement) for > > > all open orders on a session. > > > > There are however advantages for being able to specify this on an > > > individual order. You probably don't want these type of orders to be > > > canceled, even if your FIX session disconnects: > > > - Market on close orders > > > - Market on open orders > > > - Certain types of long-running algorithmic orders > > > - GTC orders > > > - Stop loss orders > > > > So it is a handy feature to allow the specification of your "cancel-upon- > > > disconnect" setting on an individual order. Without this capability > > > you will need 2 sessions: one for orders you want to be canceled and > > > the other for orders you don't want to be canceled. > > > > I notice that tag 18 (ExecInst) has several useful values in this > > > respect: K = cancel upon trading halt (added with FIX.4.3) Q = cancel > > > upon system failure (added with FIX.4.3) o = cancel upon connection > > > loss (added with FIX.5.0SP1) > > > > So there is a standard way of indicating this (18=o). > > > > Thanks > > > > JohnP > > > > > Robert, from my experience this is typically implemented on the > > > > session level, rather than per order. > > > > > > The system we are developing has the default behavior of > > > > > cancelling all open orders on abnormal disconnect (any > > > > > disconnection that is not preceded by a logout message). There is > > > > > some talk that it would be a useful feature to allow clients to > > > > > specify on a per order basis what behavior they would like on > > > > > abnormal disconnect. > > > > > > I have two questions. First, can anyone think why this would be a > > > > > terrible idea (allowing users to specify if an order persists or > > > > > is cancelled on abnormal disconnect)? And second, is there any > > > > > field in the NewOrderSingle message that might be pressed into > > > > > service to accomplish this goal, or would we have to use a non- > > > > > standard, user defined field? > > > > > > Thanks! > > [You can unsubscribe from this discussion group by sending a message to > mailto:[email protected]] > > -- > You received this message because you are subscribed to the Google Groups > "Financial Information eXchange" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/fix-protocol?hl=en. -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
