{"_id":"56b377c5023ef30d009b2b82","githubsync":"","project":"569407ac73f48f0d0075c9c9","category":{"_id":"56b2615b147e900d00d64995","pages":["56b36e000551d31900cec0ab","56b36e0cb008aa1900ab16f1","56b36e1670b0d22100be6512","56b3773f78a1212100900705","56b3778940438c1900004796","56b377b053da320d00c29742","56b377c5023ef30d009b2b82","56b3788453da320d00c29744"],"project":"569407ac73f48f0d0075c9c9","__v":8,"version":"569407ad73f48f0d0075c9cc","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-02-03T20:21:47.739Z","from_sync":false,"order":9999,"slug":"sessions","title":"Sessions"},"user":"563cc6fa8894d20d00014ea3","version":{"_id":"569407ad73f48f0d0075c9cc","project":"569407ac73f48f0d0075c9c9","__v":4,"createdAt":"2016-01-11T19:51:09.439Z","releaseDate":"2016-01-11T19:51:09.439Z","categories":["569407ae73f48f0d0075c9cd","56b25e4794ab060d00067421","56b2615b147e900d00d64995","56b3788d78a1212100900709"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"1.0.0","version":"1"},"__v":6,"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-02-04T16:09:41.412Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"settings":"","results":{"codes":[]},"auth":"required","params":[],"url":""},"isReference":false,"order":999,"body":"[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"8=FIX.4.2\\n9=99\\n34=1031\\n35=4\\n36=1034\\n43=Y\\n49=DWFIX01\\n52=20160201-22:36:16.853\\n56=TEST1\\n122=20160201-22:36:16\\n123=Y\\n10=098\",\n      \"language\": \"text\",\n      \"name\": \"Secquence Reset Request\"\n    }\n  ],\n  \"sidebar\": true\n}\n[/block]\n\nThe `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 <4>-Gap Fill`\" when `GapFillFlag <123>` is `Y` and `Sequence Reset <4>-Reset` when `GapFillFlag <123>` is `N` or not present. The `Sequence Reset <4>-Reset` 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:\n\nDuring normal resend processing, the sending application may choose not to send a message (e.g. an aged order). The `Sequence Reset <4> - Gap Fill` is used to mark the place of that message.\nDuring normal resend processing, a number of administrative messages are not resent, the `Sequence Reset <4> - Gap Fill` message is used to fill the sequence gap created.\nIn the event of an application failure, it may be necessary to force synchronization of sequence numbers on the sending and receiving sides via the use of `Sequence Reset <4> - Reset`\nThe 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.\n\nIf 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 <4> - Reset` message with an out of sequence `MsgSeqNum <34>` should not generate resend requests). `Sequence Reset <4> - Reset` should NOT be used as a normal response to a `Resend Request <2>` (use `Sequence Reset <4> - Gap Fill`). The `Sequence Reset <4> - Reset` should ONLY be used to recover from a disaster situation which cannot be recovered via the use of `Sequence Reset <4> - Gap Fill`. Note that the use of `Sequence Reset <4> - Reset` may result in the possibility of lost messages\n\nIf 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 <4>-GapFill` message should represent the beginning `MsgSeqNum <34>` in the GapFill range because the remote side is expecting that next message).\n\nThe 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 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` 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.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Tag\",\n    \"h-1\": \"Tag Description\",\n    \"h-2\": \"Value\",\n    \"h-3\": \"Value Description\",\n    \"0-0\": \"`8`\",\n    \"0-1\": \"BeginString\",\n    \"0-2\": \"`FIX.4.2`\",\n    \"0-3\": \"FIX Version\",\n    \"h-4\": \"Required\",\n    \"3-0\": \"`35`\",\n    \"3-1\": \"MsgType\",\n    \"3-2\": \"`4`\",\n    \"3-3\": \"Sequence Reset Message\",\n    \"0-4\": \"**Yes**\",\n    \"1-0\": \"`9`\",\n    \"1-1\": \"BodyLength\",\n    \"1-2\": \"`63`\",\n    \"1-3\": \"Length of message\",\n    \"1-4\": \"**Yes**\",\n    \"3-4\": \"**Yes**\",\n    \"11-0\": \"`10`\",\n    \"11-1\": \"CheckSum\",\n    \"11-2\": \"`098`\",\n    \"11-3\": \"Checksum of message\",\n    \"11-4\": \"**Yes**\",\n    \"6-0\": \"`49`\",\n    \"6-1\": \"SenderCompID\",\n    \"6-2\": \"`DWFIX01`\",\n    \"6-3\": \"Sender ID\",\n    \"6-4\": \"**Yes**\",\n    \"8-0\": \"`56`\",\n    \"8-1\": \"TargetCompID\",\n    \"8-2\": \"`TEST1`\",\n    \"8-3\": \"Target ID\",\n    \"7-0\": \"`52`\",\n    \"7-1\": \"SendingTime\",\n    \"7-2\": \"`20160201-22:36:16.853`\",\n    \"7-3\": \"Sending timestamp\",\n    \"7-4\": \"**Yes**\",\n    \"8-4\": \"**Yes**\",\n    \"2-0\": \"`34`\",\n    \"2-1\": \"MsgSeqNum\",\n    \"2-2\": \"`30`\",\n    \"2-3\": \"Message sequence number\",\n    \"2-4\": \"**Yes**\",\n    \"9-0\": \"`122`\",\n    \"9-1\": \"OrigSendingTime\",\n    \"9-2\": \"`20160201-22:36:16`\",\n    \"9-3\": \"Original time of message transmission\",\n    \"9-4\": \"**Yes**\",\n    \"10-0\": \"`123`\",\n    \"10-1\": \"GapFillFlag\",\n    \"10-2\": \"`Y`\",\n    \"10-3\": \"Indicates the message is replacing administrative or application messages which will not be resent.\",\n    \"10-4\": \"**Yes**\",\n    \"4-0\": \"`36`\",\n    \"4-1\": \"NewSeqNo\",\n    \"4-2\": \"`1034`\",\n    \"4-3\": \"New sequence number\",\n    \"4-4\": \"**Yes**\",\n    \"5-0\": \"`43`\",\n    \"5-1\": \"PossDupFlag\",\n    \"5-2\": \"`Y`\",\n    \"5-3\": \"Indicates possible retransmission of message with this sequence number. `Y` = Possible duplicate.\",\n    \"5-4\": \"**Yes**\"\n  },\n  \"cols\": 5,\n  \"rows\": 12\n}\n[/block]","excerpt":"","slug":"sequence-reset-message","type":"basic","title":"Sequence Reset"}
[block:code] { "codes": [ { "code": "8=FIX.4.2\n9=99\n34=1031\n35=4\n36=1034\n43=Y\n49=DWFIX01\n52=20160201-22:36:16.853\n56=TEST1\n122=20160201-22:36:16\n123=Y\n10=098", "language": "text", "name": "Secquence Reset Request" } ], "sidebar": true } [/block] The `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 <4>-Gap Fill`" when `GapFillFlag <123>` is `Y` and `Sequence Reset <4>-Reset` when `GapFillFlag <123>` is `N` or not present. The `Sequence Reset <4>-Reset` 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: During normal resend processing, the sending application may choose not to send a message (e.g. an aged order). The `Sequence Reset <4> - Gap Fill` is used to mark the place of that message. During normal resend processing, a number of administrative messages are not resent, the `Sequence Reset <4> - Gap Fill` message is used to fill the sequence gap created. In the event of an application failure, it may be necessary to force synchronization of sequence numbers on the sending and receiving sides via the use of `Sequence Reset <4> - Reset` 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 <4> - Reset` message with an out of sequence `MsgSeqNum <34>` should not generate resend requests). `Sequence Reset <4> - Reset` should NOT be used as a normal response to a `Resend Request <2>` (use `Sequence Reset <4> - Gap Fill`). The `Sequence Reset <4> - Reset` should ONLY be used to recover from a disaster situation which cannot be recovered via the use of `Sequence Reset <4> - Gap Fill`. Note that the use of `Sequence Reset <4> - Reset` 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 <4>-GapFill` message should represent the beginning `MsgSeqNum <34>` in the GapFill range because the remote side is expecting that next message). 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 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` 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. [block:parameters] { "data": { "h-0": "Tag", "h-1": "Tag Description", "h-2": "Value", "h-3": "Value Description", "0-0": "`8`", "0-1": "BeginString", "0-2": "`FIX.4.2`", "0-3": "FIX Version", "h-4": "Required", "3-0": "`35`", "3-1": "MsgType", "3-2": "`4`", "3-3": "Sequence Reset Message", "0-4": "**Yes**", "1-0": "`9`", "1-1": "BodyLength", "1-2": "`63`", "1-3": "Length of message", "1-4": "**Yes**", "3-4": "**Yes**", "11-0": "`10`", "11-1": "CheckSum", "11-2": "`098`", "11-3": "Checksum of message", "11-4": "**Yes**", "6-0": "`49`", "6-1": "SenderCompID", "6-2": "`DWFIX01`", "6-3": "Sender ID", "6-4": "**Yes**", "8-0": "`56`", "8-1": "TargetCompID", "8-2": "`TEST1`", "8-3": "Target ID", "7-0": "`52`", "7-1": "SendingTime", "7-2": "`20160201-22:36:16.853`", "7-3": "Sending timestamp", "7-4": "**Yes**", "8-4": "**Yes**", "2-0": "`34`", "2-1": "MsgSeqNum", "2-2": "`30`", "2-3": "Message sequence number", "2-4": "**Yes**", "9-0": "`122`", "9-1": "OrigSendingTime", "9-2": "`20160201-22:36:16`", "9-3": "Original time of message transmission", "9-4": "**Yes**", "10-0": "`123`", "10-1": "GapFillFlag", "10-2": "`Y`", "10-3": "Indicates the message is replacing administrative or application messages which will not be resent.", "10-4": "**Yes**", "4-0": "`36`", "4-1": "NewSeqNo", "4-2": "`1034`", "4-3": "New sequence number", "4-4": "**Yes**", "5-0": "`43`", "5-1": "PossDupFlag", "5-2": "`Y`", "5-3": "Indicates possible retransmission of message with this sequence number. `Y` = Possible duplicate.", "5-4": "**Yes**" }, "cols": 5, "rows": 12 } [/block]