本節描述從本地節點到應用程式的外發資料流。 上述協定的整體結構適用於系統服務控制點（SSCP）與主要邏輯單元（PLU）連線，但某些功能（如延遲請求模式）僅適用於 PLU 連線。
本地節點會根據資料流向的 SNA 會話，將來自主機的資料以不同的連線方式呈現給應用程式，具體如下：
功能管理資料網路服務（FMD NS）（會話服務）資料和功能管理資料（FMD）由主機 SSCP 發送，並指向主機整合伺服器邏輯單元（LU），然後將其傳送至透過 SSCP 連線的應用程式。
來自主機 PLU 並導向 SNA 伺服器 LU 的 FMD 資料會傳送至 PLU 連線上的應用程式。
對於所有連線，只有 FMD 請求會以 資料 訊息的形式呈現給應用程式（訊息類型 = DATAFMI）。 DFC 與會話控制請求用於產生 狀態控制 訊息。 （更多資訊請參見 Status-Control 訊息。）
本地節點會在向應用程式發送 資料 訊息前，執行請求中回應標頭（RH）指示器所需的資料流控制狀態變更。
SNA 請求傳輸標頭（TH）與 RH 指示器在外發 資料 訊息時無法供應用程式使用。 取而代之的是，本地節點會在 資料 訊息標頭中提供應用程式旗標，反映部分 RH 指示器的設定，但本地節點會解讀這些標誌，以保護應用程式免受鏈式與括號使用等較為晦澀的部分影響。 關於可用旗標的描述以及本地節點如何對外站資料使用它們，請參見 應用旗標。
對於外送資料，第一個位元組為 RU[0] 代表標準功能管理介面（FMI），邏輯單元應用程式（LUA）變體則為 TH[0]。
所有從本地節點到應用程式的資料訊息都包含訊息金鑰。 本地節點為每個向應用程式的外發資料流維護唯一的訊息金鑰序列。 當本地節點向特定連線上的應用程式發送 資料 訊息時，會將下一個訊息鍵放入訊息標頭，設定應用程式標誌，並將訊息傳送給應用程式。 這表示訊息金鑰能唯一識別本地節點與應用程式之間特定連線上的 資料 訊息。 請注意，本地節點也會將訊息金鑰放在外 Status-Control 請求 訊息上。
主機整合伺服器強制執行的確認協定反映了 SNA 會話中使用的鏈回應協定與請求模式，具體如下：
外發 RQD 請求會產生 資料 訊息，並且在訊息標頭中設定 ACKRQD。
出站 RQE 請求會產生 資料 訊息，且未設定 ACKRQD 。
外發 RQN 請求會在未設定 ACKRQD 的情況下產生資料訊息。
若會話使用主要即時請求模式，應用程式必須先確認 ACKRQD 設定的 資料 訊息，才能接收後續的 資料訊息。
若會話使用主要延遲請求模式，應用程式不必立即確認 ACKRQD 設定的資料訊息。 資料訊息將持續被接收。
請注意，主機整合伺服器對所有連線的出站資料確認協定強制執行等同的即時回應模式。 應用程式必須依序發送回覆。
若本地節點在 Data 訊息的訊息標頭中設定 ACKRQD 欄位，表示需要對該 Data 訊息進行確認。 應用程式透過向同一連線上的本地節點發送 Status-Acknowledge 訊息來確認外發 Data 訊息，該訊息包含與 Data 訊息相同的訊息金鑰與序號欄位。
收到 Status-Acknowledge（Ack） 後，本地節點會將訊息金鑰與未完成的外發訊息關聯，並對相應的 SNA 請求產生正向回應。
應用程式應使用 Status-Acknowledge（Nack-1） 訊息作為負向確認。 當收到 Status-Acknowledge（Nack-1） 時，本地節點會將該訊息與未完成的外發訊息關聯起來，並產生 SNA 的負向回應及對應 SNA 請求的感知資料。 應用程式提供應附隨於否定回應的感知資料，作為 狀態確認（Nack-1） 訊息的一部分，且必須包含與被否定確認的 資料 訊息相同的訊息鍵、應用程式旗標及序號欄位。
因加速流請求所致的狀態控制消息可隨時發送，不影響向外出正常流資料消息發送肯定或否定回應。 它們能發生在外發 資料 訊息與匹配的 狀態確認 訊息之間，純屬巧合。 關於哪些Status-Control訊息對應於 SNA 請求，請參見Status-Control 訊息。
若偵測到主機發出的正常流程請求格式錯誤，或該請求不適合該會話狀態，本地節點會產生具有以下特徵的錯誤 資料 訊息：
SDI 與 ECI 應用程式標誌已設定。
與錯誤相關的感應碼佔據 資料 訊息的前四個位元組。 （更多資訊請參見 Status-Control 訊息。）
ACKRQD 已設定好。
應用程式應回傳 Status-Acknowledge（Ack），本地節點會產生帶有與偵測錯誤相符的感知碼的負回應。 此機制可執行以下功能：
通知應用偵測到的錯誤。
允許應用程式在本地節點對此資料訊息發送負面回應前，回應先前收到的資料。
在應用程式接收一系列 RQE 鏈的會話中，本地節點會保留每條鏈的相關性資訊（以防應用程式想對任何鏈發送負面回應）。 若本地節點的關聯表條目用盡，將嘗試分配更多條目，若失敗，將被迫終止會話。 為防止此情況，應用程式應對不希望在此情況下拒絕的 RQE 資料提供 狀態確認（Ack） 訊息。 連續五次RQE鏈後的回應應該就足夠了。 這類訊息稱為禮貌確認，不會產生對主機的回應，而只是提供自由的內部相關資料。
以下六幅圖說明了本地節點與應用程式之間強制執行的資料確認協定，並展示應用程式產生正負狀態 確認e 訊息的影響。
數據顯示：
SNA 請求/回應中的相關 RH 標誌。
SNA 請求/回應的序號。
任何 Sense 資料（顯示為「SENSE=...」），用於 SNA 請求/回應及 狀態確認 訊息。
資料訊息中的ACKRQD 欄位。
資料訊息中的訊息金鑰欄位。
為了簡化起見，所有訊息都假設是在同一PLU會話中流動的FM資料。
在下圖中，應用程式接受一個與確定回應的RU對應的數據訊息。
應用程式會傳送對應確定回應 RU 的資料訊息在下圖中，應用程式接受一個對應於多 RU 確定回應鏈的 資料訊息。
應用程式接受對應多RU確定回應鏈的資料訊息在下圖中，應用程式會拒絕對應於確定回應鏈的資料訊息。
應用程式會拒絕對應於確定回應鏈的資料訊息在下圖中，應用程式會拒絕與多RU確定回應鏈相關的資料訊息。
應用程式會拒絕對應於多 RU 確定回應鏈的資料訊息在下圖中，本地節點強制執行即時反應模式。 回覆必須依序發送。 應用程式拒絕第二條例外回應鏈，並接受確定回應鏈，這表示接受第三條例外回應鏈。
本地節點強制立即回應模式在下圖中，本地節點偵測到傳送至應用程式的資料中出現鏈狀錯誤（RQD，但非 EC）。 （此範例要求接收檢查0x4007生效。更多資訊請參見 開啟SSCP連線。）
本地節點偵測到傳送至該應用程式的資料串接錯誤