developers:fixapi.sequencereset [WIKI]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Sequence Reset ======

===== Resetting Sequence Numbers =====
The Sequence Reset message requests the counterparty to change the requestor's expected sequence number. The new sequence number is indicated by the mandatory field **NewSeqNo** (Tag 36).  

Under out-of-sequence conditions, Sequence Reset messages are important as they provide a mechanism to skip message gaps that are not to be honored by a Resend Request. Sequence Resets also provide a mechanism of recovery from disaster conditions.

Sequence number resets can only **increase** the sequence number. Sequence Resets attempting to reset to a sequence number less than expected can generate a Resend Request condition or a Reject condition.

Sequence Resets are encountered in two modes:

^ Mode   ^ Tag# ^ GapFillFlag ^
| Gap Fill | 123 | Y |
| Reset    | 123 | N or absent |

----

===== Gap Fill Mode =====
Gap-Fill Sequence Resets attempt to fill the sequence number gap by indicating (with **NewSeqNo** – Tag 36) the sequence number of the message that shall be expected immediately following the skipped message gap.

Gap-Fill Sequence Resets are generated as a response to the **Resend Request** message to indicate that messages are to be skipped from the requested resend range. Messages may be ignored in a resend sequence if they are administrative (e.g. heartbeats, test requests, etc.) or the resending party chooses not to send certain messages for risk and/or age considerations.

Message gaps where multiple messages are to be ignored should be serviced by a **single Sequence Reset** and not by one Sequence Reset per message.  
For example: If a continuous gap exists for sequence numbers 89 to 95, one single Sequence Reset with **NewSeqNo (Tag 36)** = 96 should be sent.

The Gap-Fill mode Sequence Reset must conform to the protocol sequencing rules.  
Hence, the sequence number of the Gap-Fill message (**Tag 34**) must reflect the next sequence number expected by the counterparty — this should represent the beginning of the message gap. Failure to follow this rule will result in a **Resend Request**.

----

===== Reset Mode =====
The Reset mode Sequence Reset is applicable to application failures where the traditional Gap-Fill mode Sequence Reset is not able to regain normal sequence progression.  
Reset Mode Sequence Resets should only be used for **disaster recovery situations**.

The Reset Mode Sequence Reset message does not have to adhere to the protocol's sequencing rules. Therefore, a Resend Request will not be generated for an incorrect sequence number (Tag 34).  
**Note:** Use of Reset Mode Sequence Resets carries the risk of losing messages.

----

===== Recovery of Last Resort =====
If recovery is not achievable with Sequence Resets, dropping the physical connection will terminate the current FIX session and reset sequence numbers for the next FIX session. Upon reconnection, normal traffic operations will resume with sequence numbers reset to 1.  
**Note:** This approach also carries the possibility of losing messages.

----

===== Message Dictionary =====
^ Tag ^ Field Name ^ Req'd ^ Comments ^
| *Standard Header* | Y | MsgType = 4 |
| 123 | GapFillFlag | N | Indicates that the Sequence Reset message is replacing administrative or application messages which will not be resent. |
| 36  | NewSeqNo    | Y | New sequence number |
| *Standard Trailer* | Y | |

----

===== Sample Message =====

**Resetting Sequence Number to 30**
<code>
34=2|49=T4Example|56=T4|50=TraderName|52=20120906-14:14:16.424|36=30|123=Y|
</code>

<code>
[FIXSEQUENCERESET]  
[MsgSeqNum] 34 = 2  
[SenderCompID] 49 = T4Example  
[TargetCompID] 56 = T4  
[SenderSubID] 50 = TraderName  
[SendingTime] 52 = 20120906-14:14:16.424  
[NewSeqNo] 36 = 30  
[GapFillFlag] 123 = Y (YES)  
</code>


[[developers:legacy_fix_api|T4 FIX API Home]]