[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/7e9b583a - PLEASE DO NOT REPLY BY MAIL.]
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.
