SequenceReset <4> message

Description

The Sequence Reset message has two modes: Gap Fill mode and Reset mode.

Gap Fill mode is used in response to a ResendRequest (35=2) when one or more messages must be skipped over for the following reasons:

• During normal resend processing, the sending application may choose not to send a message (e.g. an aged order).
• During normal resend processing, a number of administrative messages are skipped and not resent (such as Heart Beats, Test Requests).

Gap Fill mode is indicated by GapFillFlag <123> field = "Y".

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 SequenceReset (35=4) GapFill mode message should represent the beginning MsgSeqNum <34> in the GapFill range because the remote side is expecting that next message sequence number).

Reset mode involves specifying an arbitrarily higher new sequence number to be expected by the receiver of the SequenceReset (35=4)-Reset mode message, and is used to reestablish a FIX session after an unrecoverable application failure.

Reset mode is indicated by the GapFillFlag <123> field = "N" or if the field is omitted.

If the GapFillFlag <123> field is not present (or set to N), it can be assumed that the purpose of the SequenceReset (35=4) message is to recover from an out-of-sequence condition. In SequenceReset (35=4) - Reset mode, the MsgSeqNum <34> in the header should be ignored (i.e. the receipt of a SequenceReset (35=4) - Reset mode message with an out of sequence MsgSeqNum <34> should not generate resend requests). SequenceReset (35=4) - Reset should NOT be used as a normal response to a ResendRequest (35=2) (use SequenceReset (35=4) - Gap Fill mode). The SequenceReset (35=4) - Reset should ONLY be used to recover from a disaster situation which cannot be recovered via the use of SequenceReset (35=4) - Gap Fill. Note that the use of SequenceReset (35=4) - Reset may result in the possibility of lost messages.

The sending application will initiate the SequenceReset (35=4). The message in all situations specifies NewSeqNo <36> to reset to as the value of the next sequence number to be expected by the message receipient immediately following the messages and/or sequence numbers being skipped.

The SequenceReset (35=4) 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 Resend Requests 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 ResendRequest (35=2) may appear as SequenceReset (35=4)-GapFill mode with NewSeqNo <36> of 8, message 8, SequenceReset (35=4)-GapFill with NewSeqNo <36> of 10, and message 10. This could then followed by SequenceReset (35=4)-GapFill with NewSeqNo <36> of 8, message 8, SequenceReset (35=4)-GapFill with NewSeqNo <36> of 10, message 10, and message 11. One must be careful to ignore the duplicate SequenceReset (35=4)-GapFill mode 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 SequenceReset (35=4)-GapFill mode is a duplicate and should be discarded.

Structure

Sample Messages

The ^ character is used to represent SOH character.

8=FIXT.1.1^9=107^35=4^49=SellSide^56=BuySide^34=2^43=Y^52=20190605-17:09:11.496^122=20190605-17:09:11.496^1128=9^123=Y^36=4^10=134^

Related Messages

• Resend Request <2>