[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <[email protected]> to the "4.2 Changes" discussion forum at http://fixprotocol.org/discuss/5. You can reply to it on-line at http://fixprotocol.org/discuss/read/a9e8a658 - PLEASE DO NOT REPLY BY MAIL.]
To further clarify: The party sending the order is "optimistic" that a change will succeed. If a change hasn't been acknowledged, the party sending the order will send another change or cancel using ClOrdID of the last change as the OrigClOrdID of the next change or cancel. Note that this is only true if a change isn't rejected. The party accepting the order is "pessimistic" that a change will succeed in choosing its ClOrdID. In other words, if that party responds with a Pending Replace for ClOrdID=X, OrigClOrdID=Y, and a partial fill occurs before a Replaced messages is sent, then ClOrdID=X. I hope this helps. > Your message no 2 (Cancel Request) would have OrigClOrdID = Y, > ClOrdID = Z > > Look thru "D16– One cancel/replace request is issued followed > immediately by another – broker processes sequentially" on page 219 > (221 of 283) of FIX.4.2 spec [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 -~----------~----~----~----~------~----~------~--~---
