本節描述從應用程式到本地節點的入站資料流。 上述協定的整體結構適用於系統服務控制點（SSCP）與主要邏輯單元（PLU）連線，但較複雜的部分（如延遲請求模式的使用）僅適用於 PLU 連線。
應用程式可對任一連線傳送入站資料，具體如下：
功能管理資料網路服務（FMD NS）（會話服務）及功能管理資料（FMD）用於主機 SSCP 的字元編碼資料，應傳送至 SSCP 連線上的本地節點。
預定為主機 PLU 的 FMD 資料應傳送至 PLU 連線上的本地節點。
應用程式無法使用 資料 訊息向主機傳送資料流控制（DFC）或會話控制請求訊息。 取而代之的是，必須使用 狀態控制 訊息。 （詳情請參見 Status-Control 訊息。）
對於所有連線，應用程式必須在 資料 訊息標頭中填入特定關鍵欄位。 具體要求必須：
將訊息類型設為 DATAFMI。
在此連線上為入站 資料 訊息配置新的訊息金鑰。
如果需要，可以設定 ACKRQD 欄位。
設定應用程式標誌。 （更多資訊請參見 應用程式標誌。）
訊息標頭中的 nxtqptr、 hdreptr 和 numelts 欄位，以及訊息元素中的 elteptr 和 startd 欄位，皆由主機整合伺服器緩衝區管理例程設定。 （更多資訊請參見 DL-BASE/DMOD 介面。）應用程式負責設定 endd 欄位。
若應用程式無法存取這些例程（例如，當作業系統不支援任務間程序呼叫與共享記憶體時），標頭中的所有欄位必須由應用程式自行設定。
對於輸入 資料 訊息，應用程式無法使用傳輸標頭（TH）與回應標頭（RH）指示。 應用程式應在訊息標頭中設定適當的應用程式標誌，以控制鏈條、方向等。 關於可用於入站資料的應用程式旗標說明，以及本節後續主題如何說明這些旗標如何控制入站資料流，請參見 應用程式旗標。
對於入站資料，第一個位元組為 RU[0]，代表標準功能管理介面（FMI）。
應用程式在入站資料訊息標頭中提供的訊息金鑰，由本地節點用來指示該連線中出站狀態確認所指的哪一則資料訊息。 應用程式應在每個與本地節點的連線中，為入站資料流維持唯一的訊息金鑰序列，以便應用程式能利用訊息金鑰來關聯連線上的入站 資料 訊息與出站 狀態確認 訊息。 請注意，應用程式還必須在 Status-Control Request 訊息中提供訊息金鑰，以區分多個 RQE LUSTAT 訊息。
入站資料確認協定反映了該會話中使用的次級鏈回應協定及請求模式，具體如下：
入站資料訊息，其標頭中設定ACKRQD，這會生成RQD請求。
未在標頭設定 ACKRQD 的入站資料訊息會根據鏈式回應協定產生 RQE 或 RQN 請求。
應用程式應僅對設定端鏈指示器（ECI）應用程式標誌的資料訊息設定ACKRQD。
若會話指定次要端使用即時請求模式，應用程式在設定 ACKRQD 後仍可發送更多資料訊息，即使未收到該資料訊息的狀態確認訊息。 訊息會排隊於本地節點內，隨著收到正面回應而逐步發送。
若會話指定次要端使用延遲請求模式，在發送設定為 ACKRQD的資料訊息後，應用程式仍可繼續發送資料訊息。
若應用程式在 Data 訊息的訊息標頭中設定 ACKRQD 欄位，表示需要對該 Data 訊息進行確認。 本地節點透過在同一連線上向應用程式發送 Status-Acknowledge 訊息，並使用與資料訊息相同的訊息金鑰來確認收到的 Data 訊息。 （說明請見本主題末尾的第一幅圖。）
本地節點透過內部狀態電腦處理來自應用程式的入站 資料 訊息，為此流程指派正確的 SNA 序號或識別碼，並將資料以請求方式傳送給主機。 請求的鏈回應類型取決於資料訊息中是否設定了 ACKRQD 以及會話參數。
本地節點將主機的正面回應對應到應用程式中的狀態確認（Ack）。 應用程式可利用 狀態確認 中的訊息鍵，將確認與原始 資料 訊息對應。 因此，收到特定資料訊息的狀態確認（Ack）表示該本地節點已收到主機對入站 SNA 請求的正面回應。 （說明請見本主題末尾的第二幅圖。）
請注意，回覆會在 SSCP-PU 會議中被吸收。
請注意，外發的 Status-Acknowledge（Ack） 訊息包含應用程式旗標和序號。 應用標誌反映響應中的相對濕度指標。 序號是回應的 SNA 序號，為使用 Transmission Service profile （TS profile） 4 的應用程式追蹤對應工作單元的 SNA 次要序號提供機制。
本地節點會將主機對應 Status-Acknowledge（Nack-1） 訊息的負面回應映射給應用程式。 應用程式可利用 狀態確認 中的訊息鍵將負向確認與原始 資料 訊息關聯起來。 出站 狀態確認（Nack-1） 訊息包含來自否定回應的 SNA 感知碼與序號。 （說明請見本主題末尾的第三及第四幅圖。）
若本地節點偵測到入站資料訊息格式錯誤，或該資料訊息不符合會話當前狀態，則會向應用程式發送包含錯誤碼的狀態確認（Nack-2）。 （關於錯誤代碼列表，請參見 錯誤與感知代碼。）本地節點不會向主機發送與錯誤的 資料訊息 相關的請求，也不會增加該會話的系統網絡架構（SNA）序號。 應用程式可以在下一個入站 資料 訊息中使用任何訊息金鑰（假設錯誤不會導致嚴重失敗）。
本主題末尾最後一幅圖展示了一個嚴重鏈式錯誤的例子，即應用程式傳送帶有 ACKRQD 但應用程式標誌中未包含 ECI 的資料訊息。 請注意，偵測到此錯誤後，本地節點會將應用程式的連線標記為嚴重失敗，關閉連線，並向 SSCP 發送 TERM-SELF 請求以觸發 UNBIND。 （更多資訊請參見 復原。）
導致加速流請求產生的入站 狀態控制 訊息可隨時發送，且不影響向入站 資料 訊息發送正面或負面確認。 關於哪些 狀態控制 訊息對應於 SNA 加速流程請求，請參見 Status-Control 訊息。
以下五幅圖展示了不同鏈回應類型及次級會話請求模式的入站資料確認協定（及底層 SNA 協定）範例。
數據顯示：
資料訊息的ACKRQD欄位。
資料 訊息的訊息鍵。
Data 訊息上 有沒有相關的應用程式標誌。
資料 訊息上的 錯誤代碼（顯示為「ERROR=...」）。
SNA 請求/回覆中相關的 RH 標記。
SNA 請求/回應的序號。
SNA 請求/回應上的 Sense 代碼（顯示為「SENSE=......」）。
為了簡化起見，假設所有訊息都在同一個 PLU 會話中傳遞。
在下圖中，應用程式成功傳送了一則資料訊息。
應用程式成功傳送資料訊息在下圖中，應用程式成功傳送了一串 資料 訊息。
應用程式成功傳送一連串資料訊息在下圖中，主機拒絕了一連串 資料 訊息。
主機拒絕一連串的資料訊息在下圖中，主機在延遲請求會話中拒絕第一個確定回應鏈，並拒絕第三個例外回應鏈。 注意，對第三條鏈的負面反應意味著對第二條鏈有正面反應。
主機拒絕了第一個確定回應鏈在下圖中，本地節點偵測應用程式在資料訊息中未使用 ECI 應用程式標誌時使用 ACKRQD 的無效情況。 請注意，沒有任何資料會傳送給主機。 然而，由於錯誤嚴重，本地節點會向 SSCP 發送 TERM-SELF 訊息。
圖
本地節點偵測到在資料訊息上未有 ECI 應用程式標誌時，應用程式無效使用 ACKRDQ