STSN

設定及測試 STSN) (序號，會用於具有傳輸服務設定檔的會話 (TS 設定檔) 4，應用程式可維護會話之間的交易處理序號。 這可讓會話上的兩個夥伴探索 CLEAR 或 UNBIND–BIND 序列之後遺失的資料量。

STSN訊息是唯一可以重設這類交易處理序號的訊息。 BIND、 UNBIND和 CLEAR 不會影響它們。

如果應用程式想要維護這類交易號碼，則必須在Open (PLU) OK Response中指定APPLTRAN選項。 主機可以在BIND或CLEAR之後傳送STSN，再傳送SDT來設定或測試應用程式的交易號碼。 本機節點會在收到 BIND 或 CLEAR時將其內部會話序號重設為零。 當本機節點收到 STSN ，指定一個半會話 的 SET (或 SET 和 TEST) 時，它會重設對應的內部會話序號。

除非 (動作位元組0x00) 忽略這兩個半會話動作，否則 STSN 要求會傳遞至應用程式 (，前提是其指定 APPLTRAN) ，且要求中有動作位元組和來自要求的兩個序號，做為 Status-Control (STSN) 。 (如需詳細資訊，請參閱 Status-Resource.) 應用程式必須檢查動作位元組，以判斷動作是否為忽略、設定、測試或設定及測試。 應用程式必須視需要傳送正回應 (狀態控制 (STSN) 認可) 至 STSN，並視需要 (感知序號或設定及測試) 。 本機節點負責為 STSN RSP產生正確的結果碼。

請注意，應用程式應該藉由) 分別檢查次要對主要流程的位 0 和 2，以及主要對次要流程的位 0 和 2，執行 STSN 第一個 (的感知部分。 接著會檢查動作位元組) 的位 1 和 3，以執行 STSN 的集合部分 (。

當從主機傳送和接收一般流程要求/回應單位時，應用程式應該遞增其交易號碼 (RU) 。 (請注意，對應至一般流程資料流程 控制的狀態控制 訊息， (DFC) 要求會導致交易編號遞增。) 序號會報告 于 DATAFMI 訊息和 狀態通知 訊息上。 應用程式應該注意，如果來自主機的訊息無法接收檢查 (並轉換成 SDI 訊息) ，子網路存取通訊協定 (SNAP) -2.1 將會清除主機鏈結的其餘部分，而且應用程式可能會遺漏一些序號。 因此，應用程式應該在處理 SDI 訊息之後，從下一個輸出資料重設其主要對次要事務編號。

請注意，第二個應用程式旗標位元組對 Status-Control (STSN) 無效。 它用於 STSN 控制位元組。

另請參閱

應用程式 CANCEL
收到負值回應後的方向
傳送負值回應後的方向
嚴重失敗
RQR 和 CLEAR
連結服務失敗
本機節點失敗
用戶端失敗