[This message was posted by Robert Mitchell of NYU <[email protected]> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/f2d4e357 - PLEASE DO NOT REPLY BY MAIL.]
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 at http://groups.google.com/group/fix-protocol?hl=en.
