輸出資料

本節說明從本機節點流向應用程式的輸出資料流程。 描述之通訊協定的整體結構適用于系統服務控制點 (SSCP) 和主要邏輯單元, (PLU) 連線,但某些功能 (例如使用延遲要求模式) 僅適用于 PLU 連線。

本機節點會根據資料流程所依據的 SNA 會話,將源自主機的資料呈現至不同連線上的應用程式,如下所示:

  • 函式管理資料網路服務 (FMD NS) (會話服務) 資料和函式管理資料 (FMD) 源自主機 SSCP,並導向至主機整合伺服器邏輯單元, (LU) 會傳送至 SSCP 連線上的應用程式。

  • 源自主機 PLU 並導向至 SNA 伺服器 LU 的 FMD 資料會傳送至 PLU 連線上的應用程式。

    對於所有連線,只有 FMD 要求會以 資料 (訊息類型 = DATAFMI) 的形式呈現給應用程式。 DFC 和會話控制要求是用來產生 狀態控制 訊息。 (如需詳細資訊,請參閱 Status-Control Message.)

    本機節點會先執行回應標頭 (RH) 指標所需的資料流程控制狀態變更,再將 資料 訊息傳送至應用程式。

    輸出 資料 訊息上的應用程式無法使用 SNA 要求傳輸標頭 (TH) 和 RH 指標。 相反地,本機節點會在 資料 訊息標頭中提供應用程式旗標,以反映 RH 指標子集的設定,但會由本機節點解譯,以防護應用程式免于鏈結和括弧用法的更模糊層面。 如需可用旗標的描述,以及本機節點在輸出資料上使用它們的方式,請參閱 應用程式旗標

    針對輸出資料,第一個位元組是標準函式管理介面的 RU[0], (FMI) ,而邏輯單元應用程式 (LUA) variant 的 TH[0]。

    從本機節點到應用程式的所有 資料 訊息都包含訊息金鑰。 本機節點會針對應用程式的每個輸出資料流程維護唯一的訊息金鑰序列。 當本機節點將 資料 訊息傳送至特定連線上的應用程式時,會將下一個訊息索引鍵放在訊息標頭中、設定應用程式旗標,並將訊息傳送至應用程式。 這表示訊息索引鍵可唯一識別本機節點與應用程式之間特定連線上的 資料 訊息。 請注意,本機節點也會在輸出 狀態控制要求 訊息上放置訊息金鑰。

    主機整合伺服器強制執行的通知通訊協定會反映 SNA 會話上使用的鏈結回應通訊協定和要求模式,如下所示:

  • 輸出 RQD 要求會產生 訊息標頭中設定 ACKRQD 的資料 訊息。

  • 輸出RQE要求會產生沒有ACKRQD設定的資料訊息。

  • 輸出RQN要求會產生未設定ACKRQD的資料訊息。

  • 如果會話使用主要立即要求模式,則應用程式必須認可具有ACKRQD 集的資料訊息,才能收到進一步的資料訊息。

  • 如果會話使用主要延遲的要求模式,則應用程式不需要立即認可具有ACKRQD 集合的資料訊息。 資料 訊息將繼續接收。

    請注意,主機整合伺服器會對所有連線強制執行輸出資料通知通訊協定的立即回應模式。 應用程式必須依序傳送通知。

    如果本機節點在資料訊息的訊息標頭中設定ACKRQD欄位給應用程式,則表示需要此資料訊息的通知。 應用程式會透過將Status-Acknowledge訊息傳送至相同連線上的本機節點來認可輸出資料訊息,其中包含與資料訊息相同的訊息索引鍵和序號欄位。

    在收到 Status-Receive (Ack) 時,本機節點會將訊息金鑰與未處理的輸出訊息相互關聯,並產生與適當 SNA 要求的 SNA 正面回應。

    應用程式應該使用 Status-Acknowledge (Nack-1) 訊息作為負面通知。 在收到 Status-Receive (Nack-1) 時,本機節點會將訊息與未處理的輸出訊息相互關聯,並產生 SNA 負回應,並將感知資料與適當的 SNA 要求產生。 應用程式提供應該隨附于Status-Acknowledge (Nack-1) 訊息時隨附之負回應的感知資料,而且必須包含相同的訊息索引鍵、應用程式旗標和序號欄位,做為負通知的資料訊息。

    由加速流程要求所造成的狀態控制訊息可以隨時傳送,且不會影響對正常流程輸出資料訊息的正面或負面通知傳送。 輸出 資料 訊息與相符 的 Status-Acknowledge 訊息之間可能發生的事實完全是一致的。 如需哪些 狀態控制 訊息對應至 SNA 要求的詳細資訊,請參閱 狀態控制訊息

    如果以來自主機的一般流程要求格式偵測到錯誤,或要求不適合會話的狀態,本機節點就會為具有下列特性的應用程式產生錯誤 資料 訊息:

  • 已設定 SDI 和 ECI 應用程式旗標。

  • 與錯誤相關聯的感知程式碼會佔用 資料 訊息的前四個位元組。 (如需詳細資訊,請參閱 Status-Control Message.)

  • 已設定 ACKRQD

    應用程式應該會傳回 Status-Acknowledge (Ack) ,而本機節點會產生負回應,並具有適合偵測到錯誤的感知程式碼。 此機制會執行下列動作:

  • 通知應用程式偵測到的錯誤。

  • 允許應用程式在本機節點傳送負回應至此資料訊息之前,回應任何先前收到的資料。

    在應用程式接收一系列 RQE 鏈結的會話上,如果應用程式想要將負面回應傳送至任何鏈結) ,本機節點將會保留每個鏈結的相互關聯資訊 (。 如果本機節點用完相互關聯資料表專案,它會嘗試配置更多專案,如果失敗) 將強制終止會話,則會嘗試配置更多專案,並 (。 為避免這種情況,應用程式應該為 RQE 資料提供 Status-Acknowledge (Ack) 訊息,而 RQE 資料在此案例中不想要拒絕。 在五個連續 RQE 鏈結之後的回應應該就足夠。 這類訊息稱為「請求通知」,不會引發主機的回應,但只會釋放內部相互關聯資料。

    下列六個圖說明本機節點與應用程式之間強制執行的資料通知通訊協定,並顯示產生正面和負面 狀態通知e 訊息的應用程式影響。

    圖表顯示:

  • SNA 要求/回應中的相關 RH 旗標。

  • SNA 要求/回應的序號。

  • 任何感知資料 (顯示為 「SENSE=...」,) SNA 要求/回應和 Status-Receive 訊息。

  • [資料訊息] 中的[ACKRQD] 欄位。

  • 資料訊息中的訊息索引鍵欄位。

    為了簡單起見,系統會假設所有訊息都是在相同的 PLU 會話上流動的 FM 資料。

    在下圖中,應用程式會接受對應至明確回應 RU 的資料 訊息。

    顯示應用程式如何傳送對應至明確回應 RU 的資料訊息的影像。
    應用程式會傳送對應至明確回應 RU 的資料訊息

    在下圖中,應用程式會接受對應至多重 RU 明確回應鏈結 的資料 訊息。

    顯示應用程式如何接受對應至多重 RU 明確回應鏈結之資料訊息的影像。
    應用程式接受對應至多重 RU 明確回應鏈結的資料訊息

    在下圖中,應用程式會拒絕對應至明確回應鏈結 的資料 訊息。

    顯示應用程式如何拒絕對應至明確回應鏈結之資料訊息的影像。
    應用程式拒絕對應至明確回應鏈結的資料訊息

    在下圖中,應用程式會拒絕對應至多重 RU 明確回應鏈結 的資料 訊息。

    顯示應用程式如何拒絕對應至多重 RU 明確回應鏈結的資料訊息的影像。
    應用程式拒絕對應至多重 RU 明確回應鏈結的資料訊息

    在下圖中,本機節點會強制執行立即回應模式。 回應必須依序傳送。 應用程式會拒絕第二個例外狀況回應鏈結,並接受明確回應鏈結,這表示接受第三個例外狀況回應鏈結。

    顯示本機節點強制執行立即回應模式的影像。
    本機節點會強制執行立即回應模式

    在下圖中,本機節點會偵測 (RQD 的鏈結錯誤,但不會在目的地為應用程式的資料中) EC。 (此範例需要強制接收檢查0x4007。如需詳細資訊,請參閱 開啟 SSCP 連線。)

    顯示本機節點如何偵測目的地為應用程式之資料的鏈結錯誤影像。
    本機節點會在目的地為應用程式的資料中偵測鏈結錯誤

另請參閱

輸入資料
來自 LUA 應用程式的輸入資料