Set and test sequence number（STSN）用於具有傳輸服務規範（TS profile）4 的會話，用於應用程式在會話間維持交易處理序號。 這讓會話中的雙方都能發現在 CLEAR 或 UNBIND–BIND 序列後遺失的資料量。
STSN 訊息是唯一能重設此類交易處理序列號的訊息。 BIND、UNBIND 和 CLEAR 都不會影響它們。
若應用程式想維持此類交易編號，必須在 Open（PLU） OK 回應中指定 APPLTRAN 選項。 主機可以在 BIND 或 CLEAR 後再發送 STSN 以設定或測試應用程式的交易編號。 當地節點在收到 BIND 或 CLEAR後，會將其內部會話序號重置為零。 當本地節點收到指定 SET（或 SET 與 TEST）作為半會話的 STSN 時，會重置對應的內部會話序列號。
除非兩個半會話動作都被忽略（動作位元組為 0x00），否則 STSN 請求會以 Status-Control（STSN） 的形式傳遞給應用程式（前提是指定 APPLTRAN），並附帶動作位元組與請求中的兩個序號。 （更多資訊請參見 狀態資源。）應用程式必須檢查動作位元組，以判斷該動作是忽略、設定、測試，還是設定並測試。 應用程式必須向 STSN 發送正向回應（Status-Control（STSN）確認），如有需要（偵測或集合測試）並附上偵測到的序號。 本地節點負責產生 STSN RSP 的正確結果碼。
請注意，應用程式應先執行 STSN 的意義部分（透過檢查動作位元組的第 0 和第 2 位元，分別用於次級到主級流程和主對次級流程）。 接著執行 STSN 的設定部分（透過檢查動作位元組的第 1 和第 3 位元）。
應用程式在從主機發送及接收正常流程請求/回應單元（RU）時，應增加交易編號。 （注意，對應於一般流量資料流控制（DFC）請求的 狀態控制 訊息會使交易編號增加。） 序號會在 DATAFMI 訊息及 狀態確認 訊息中回報。 應用程式應注意，若主機訊息未通過接收檢查（且轉換為 SDI 訊息），子網路存取協定（SNAP）-2.1 會清除主機鏈的其餘部分，應用程式可能會遺漏部分序號。 因此，應用程式在處理 SDI 訊息後，應從下一個出站資料中重設其主到次要交易號碼。
請注意，第二個應用程式標誌位元組對 狀態控制（STSN）無效。 它用於 STSN 控制位元組。
另請參閱
申請取消
收到負面回應後的方向
發送負面回覆後的指示
關鍵失敗
RQR 與 CLEAR
連結服務故障
本地節點故障
客戶端故障