Structure | Sample Message | Related Messages DescriptionThe Sequence Reset <4> message is used by the sending application to reset the incoming sequence number on the opposing side. This message has two modes: "Sequence Reset-GapFill <4>" when GapFillFlag <123> is 'Y' and "Sequence Reset-Reset <4>" when GapFillFlag <123> is N or not present. The "Sequence Reset-Reset <4>" mode should ONLY be used to recover from a disaster situation which cannot be otherwise recovered via "Gap Fill" mode. The Sequence Reset <4> message can be used in the following situations:
The sending application will initiate the sequence reset. The message in all situations specifies NewSeqNo <36> to reset as thevalue of the next sequence numberimmediately following the messages and/or sequence numbers being skipped. If the GapFillFlag <123> field is not present (or set to N), it can be assumed that the purpose of the Sequence Reset <4> message is to recover from an out-of-sequence condition. The MsgSeqNum <34> in the header should be ignored (i.e. the receipt of a Sequence Reset-Reset <4> message with an out of sequence MsgSeqNum <34> should not generate resend requests). Sequence Reset-Reset <4> should NOT be used as a normal response to a Resend Request <2> (use Sequence Reset-GapFill <4>). The Sequence Reset-Reset <4> should ONLY be used to recover from a disaster situation which cannot be recovered via the use of Sequence Reset-GapFill <4>. Note that the use of Sequence Reset-Reset <4> may result in the possibility of lost messages If the GapFillFlag <123> field is present (and equal to Y), the MsgSeqNum <34> should conform to standard message sequencing rules (i.e. the MsgSeqNum <34> of the Sequence Reset-GapFill <4> message should represent the beginning MsgSeqNum <34> in the GapFill range because the remote side is expecting that next message sequence number). The sequence reset can only increase the sequence number. If a sequence reset is received attempting to decrease the next expected sequence number the message should be rejected and treated as a serious error. It is possible to have multiple ResendRequests <2> issued in a row (i.e. 5 to 10 followed by 5 to 11). If sequence number 8, 10, and 11 represent application messages while the 5-7 and 9 represent administrative messages, the series of messages as result of the Resend Request <2> may appear as SeqReset-GapFill <4> with NewSeqNo <36> of 8, message 8, SeqReset-GapFill with NewSeqNo <36> of 10, and message 10. This could then followed by SeqReset-GapFill with NewSeqNo <36> of 8, message 8, SeqReset-GapFill with NewSeqNo <36> of 10, message 10, and message 11. One must be careful to ignore the duplicate SeqReset-GapFill which is attempting to lower the next expected sequence number. This can be detected by checking to see if its MsgSeqNum <34> is less than expected. If so, the SeqReset-GapFill is a duplicate and should be discarded. Structure
Sample MessageThe '^' character is used to represent SOH character. 8=FIX.4.3^9=100^35=4^49=SellSide^56=BuySide^34=2^43=Y^52=20190605-17:38:53.199^122=20190605-17:38:53.199^123=Y^36=4^10=253^
Related Messages |
||||||||||||||||||||||||