[This message was posted by Barry Hunt of <[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/a4be72cd - PLEASE DO NOT REPLY BY MAIL.]
You may also wish to consider whether this actually is a resend or not, before rejecting. PossResend=Y indicates that the broker may *possibly* be a resend - you should check yourself to see if the message has actually already been received (using ExecID - which will be the same in both the original and the possibly resent message). If you have already received it (your example indicates that you have), then you should ignore it. If you hadn't already received it, then you should probably reject it. In step 3, is 39=5 or 39=0? > After step 2 the original order (11=1001) is gone and should never be > mentioned again. So if you receive executions for ClOrdID 1001 I would > reply with a DK. However, the message in step 3 makes me believe the > broker is experiencing some sort of race condition with it's outbound > queues since 97=Y indicates that this information may have been > previously sent in a message with a different sequence number. So in > this case I'd reply with a DK and also issue an OrderStatus to force the > broker to reiterate the position. > > -Greg > > > > I have a problem regarding Tag#11 Tag#41 and Tag#97 - Example > > > given below > > > > > > 1. 35=D 97=N 11=1001 -> 35=8 39=A -> 35=8 39=0 > > > > > > 2. 35=G 97=N 11=1003 41=1001 -> 35=8 39=E 11=1003 -> 35=8 39=5 > > > 11=1003 Here tag#11 is changed to 1003 > > > > > > 3. 35=8 97=Y 11=1001 For this should I respond with an OrderStatus > > > or treat as a New Order as tag#11 is changed??? > > > > > > Thanks in advance. Amiya. > > > > Based upon on ur question: As per (1) your (ClOrdID)11 =1001, then as > > per (2) you are sending out a Cancel/Replace request hence 35=G > > (Cancel Replace Request) as a result (ClOrdID)11= 1003 (basically a > > new value) and tag 41 =1001 which is basically a tag telling you that > > the present ClOrdID references to an earlier ClordID on which a > > Cancel/Replace was performed. > > > > If you see clearly in (2) you are sending out a cancel replace request > > hence the ClOrdID tag 11 will have the same value in its Execution > > Report (35=8) as it had in the cancel/replace request message(35=G) , > > the only time this may change is if you do a cancel replace again. > > > > Hence if you again receive an execution report wiht the earlier > > ClOrdID as 11=1001 you can reject this with 35=3 since now the ClOrdID > > you are expecting is 11=1003. > > > > Thanks, Kaustubh [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 -~----------~----~----~----~------~----~------~--~---
