[This message was posted by Bivas Mishra of Wipro Technologies
<[email protected]> to the "4.4 Changes" discussion forum at
http://fixprotocol.org/discuss/17. You can reply to it on-line at
http://fixprotocol.org/discuss/read/528d803e - PLEASE DO NOT REPLY BY MAIL.]
Thanks.
I do agree that FIX should not mandate one approach or the other.
As mentioned in your post below, OrderCancelRejects might be used to convey
more details other than just the Ack. However, one issue here is that Tag 434
(CxlRejResponseTo), which is a mandatory tag in the OrderCancelReject message,
has valid enums as {1 = Order cancel request & 2 = Order cancel/replace
request}.
Of these two values the nearest value that can be used (for lack of other
options) would be Tag 434 = 1 to represent OrderMassCancelRequest as the
respondee, even though it may not be entirely accurate.
Alternatively, it's best to use the NoAffectedOrders group and completely avoid
this ambiguity in the OrderCancelReject messages.
Regards,
Bivas
> You are correct, the report is the immediate response. As you need to at
> least convey which orders have actually been cancelled, you have to
> either used the repeating group embedded in the report or individual
> ExecutionReports for each order. If you need to convey outside of the
> report (NotAffectedOrdersGrp) that an order could not be cancelled, the
> OrderCancelReject is the only available message. It can then be seen as
> a response to an OrderCancelRequest, i.e. OrderMassCancelRequest is
> simply a shortcut for one cancel request per order.
>
> The scope of orders that are affected by a mass cancel request is
> debatable and my view is that only active orders qualify if performance
> is relevant. In many exchange environments, non-active orders cannot be
> inquired any more.
>
> The group of (un)affected orders is optional as FIX does not want to
> force you to use it. As you point out, a series of ExecutionReports and
> OrderCancelRejects can also be used. If you need more than a simple ACK
> per order (e.g. remaining qty at the time of deletion), that might be
> the better way but it means more time and more processing. I do not
> think FIX should mandate one or the other. The Rules of Engagement
> should always have a chapter on message flows to explain what goes back
> and forth for every type of business process. A simple list of message
> layouts is not enough to understand the details needed to implement
> against a FIX interface. The standard spec cannot describe all possible
> flows which sometimes leads to ambiguities. Posting questions like you
> did is a recommended approach for such cases.
>
> Regards, Hanno.
>
>
> > Hi Hanno,
> >
> > Though the 'OrderMassCancelReport' seems to be the most logical
> > response to a 'OrderMassCancelRequest', the specs (Ref. FIX5.0SP2-Vol-
> > 4, Pg-117) mentions that: "The Order Mass Cancel Report is used to
> > acknowledge an Order Mass Cancel Request. Note that each affected
> > order that is canceled is acknowledged with a separate Execution
> > Report or Order Cancel Reject message."
> >
> > Also Ref. FIX5.0SP2-Vol-4, Pg-113 which states that:
> >
> > "An immediate response to this message is required. It is recommended
> > that an ExecutionRpt with ExecType=Pending Cancel be sent unless the
> > Order Mass Cancel Request can be immediately accepted (ExecutionRpt
> > with ExecType=Canceled) or rejected (Order Cancel Reject message)."
> >
> > This is a bit confusing.
> >
> > Since the 'NoAffectedGroups' and 'NoNotAfectedGroup' components are
> > optional goups in the Mass Order Handling Messages, can it be safely
> > assumed that the immediate response to the 'OrderMassCancelRequest'
> > should be an 'OrderMassCancelReport' followed by Execution Reports or
> > Order Cancel Rejects for all the individual orders?
> >
> > Although, this approach for implementation does make it a very lengthy
> > and time taking process for cancellation notification.
> >
> > More clarity on the same would definitely be helpful :-)
> >
> > Regards, Bivas
> >
> > > The response to a mass cancel request is a mass cancel report. The
> > > OrderCancelReject can only reject modification or deletion requests
> > > for individual orders. The mass cancel response has a repeating
> > > group AffectedOrdGrp where you can send those that were deleted. By
> > > definition, all others were not deleted (for whatever reason).
> > >
> > > If you look beyond FIX 4.4 you can see how the functionality has
> > > been further developed by adding a repeating group of orders that
> > > were not affected. Here you could convey those that have been filled
> > > and can thus not be deleted. The original idea for this was to
> > > convey things like locked orders that only temporarily prevent
> > > deletion.
> > >
> > > In general I would say that none of the orders that have reached end
> > > of life should be included in the lookup of orders that meet the
> > > matching criteria of the mass cancel request. Otherwise, you also
> > > have to convey orders that have expired or have been cancelled by
> > > the user. An Algo trader issuing a mass cancel is not interested
> > > about the many orders he has previously entered and cancelled.
> > >
> > > The mass cancel should only apply to active orders that can still be
> > > matched against other orders.
> > >
> > > Regards, Hanno.
> > >
> > >
> > > > Hi All,
> > > >
> > > > We are in the process of implementing OrderMassCancel Request;
> > > > Need your help on how to handle a particular instance on server
> > > > side (simulator). Below is the scenario,
> > > >
> > > > Client sends OrderMassCancel Request to server (Simulator) and
> > > > specifies Matching criteria would be Tag 530=4 (CxlOrdersCFICode)
> > > > and 461(CFIcode)=ESXXXX. So all the orders which is having 461=
> > > > ESXXXX on the server side should be cancelled.
> > > >
> > > > There are some of the orders which is having 461=ESXXXX are fully
> > > > filled and Serve sends cancelreject message to client for fully
> > > > filled order. My question is,
> > > > 1. What will be the values of 11 and 41 in 35=9 message? Since
> > > > both are mandatory tags in 35=9 message.
> > > > 2. And what will be the value of 434(CxlRejResponseTo) in 35=9
> > > > message??
> > > >
> > > > Thanks in advance Binayakumar patel
[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.
