[This message was posted by Hanno Klein of Deutsche Börse Systems
<[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/899f484f - PLEASE DO NOT REPLY BY MAIL.]
I agree that CxlRejResponseTo might not be 100% accurate semantically but the
response can be uniquely associated with the request nonetheless. The response
message OrderCancelReject carries the ID of the deletion request message in tag
11 ClOrdID. The same field is used in both the OrderCancelRequest and the
OrderMassCancelRequest. The submitter of the request can thus identify whether
the single or mass request triggered the reject. This is due to the fact that
ClOrdID serves both as an entity and a message identifier. I would prefer to
separate the two concepts but they are quite fundamental.
> 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 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.
