[This message was posted by Hanno Klein of Deutsche Börse Systems 
<[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/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 at 
http://groups.google.com/group/fix-protocol?hl=en.

Reply via email to