共用方式為

開啟 SSCP 的資源位置

  • 發行項

嘗試在多個本機節點上尋找免費的邏輯單元 (LU) 時，應用程式不需要知道哪個本機節點擁有 LU。 DL-BASE 負責使用所述的機制來尋找適當的本機節點。 描述旨在協助解譯涉及之訊息流程的追蹤，而且不需要撰寫應用程式

Open (SSCP) Request中的 open force 類型欄位會指定強制或非強制的 Open。 如果 Open 預定的 LU 沒有作用中的系統服務控制點， (SSCP) 會話，因為其連結為非使用中，強制 Open 會指示本機節點嘗試啟動連結和 SSCP 會話。 只有在 SSCP 會話已使用中，且傳回錯誤碼表示 LU 連線的狀態時，非強制 Open 才會成功。

當應用程式發出 Open (SSCP) Request時，它不會設定開啟強制類型欄位。 DL-BASE 會接著對每個節點發出非強制的 Open，直到它找到已有作用中 SSCP 會話的 LU 為止。 如果沒有這些 Open 成功，DL-BASE 就會對傳回最佳錯誤碼的節點發出強制 Open，也就是最可能啟用會話的節點。

下圖中的範例訊息流程顯示兩個本機節點的這個程式。 DL-BASE 會使用非強制的 Opens 來逐一嘗試。 節點的錯誤碼 #2 表示比節點更可能啟用 SSCP 會話 #1，因此 DL-BASE 會傳送強制開啟節點 #2。 應用程式只會知道第一個要求及其回應。

顯示兩個本機節點之範例訊息流程的影像。
兩個本機節點的範例訊息流程

若要讓應用程式在中斷失敗 (之後重新開機，例如終止 3270 模擬程式) ，本機節點也會接受來自失敗且已重新開機之應用程式的 Open (SSCP) 要求 ，並提供相同的來源位置、合作夥伴、索引 (LPI) 欄位。 在此情況下，如果 LU 已系結， TERM-SELF 訊息就會傳送至主機。

應用程式會透過 APPL 記錄與組態檔中的 LU 或 LU 群組記錄之間的關聯性來選取應用程式通訊的 SNA 伺服器 LU。 應用程式會使用 Open (SSCP) Request上的來源名稱欄位來指定名稱。 本機節點會填入 LU 或 LU 組號、在 LU 群組內選取未使用的 LU， (如果關聯與 LU 群組) ，並通知在 Open (SSCP) 回應上套用此 LU 號碼。

Open (SSCP) Request指定下列專案：

  • 來源應用程式名稱。

  • 應用程式可以使用的資源識別碼，將傳送至應用程式的 Open (PLU) 要求 相互關聯。 (如需詳細資訊，請參閱 開啟 PLU Connection.)

  • 連線資訊控制區塊，指定回應標頭使用方式，會檢查本機節點是否應該針對 LU 執行。 如果程式碼的欄位設定為0x01，接收檢查將會由本機節點的資料流程控制層在從主機抵達的資料上執行。 對應的傳送檢查不會受到影響，而且一律會執行。 提供連線資訊控制區塊，因為這些接收檢查在 SNA 中是選擇性的。 不過，預期大部分的應用程式都需要執行所有這些檢查， (設定為0x01) 的所有值。

  • 指出應用程式是否被視為高優先順序或低優先順序的指標。 所有 SNA 伺服器 3270 RU 都會標示為高優先順序， (印表機不會傳送大量的資料輸入) 。 高優先順序的效果是讓資料在忙碌中時，讓主機更快速地進行資料。

  • 指定應用程式是否為 LUA 的指標。 這會決定本機節點和應用程式是否會使用函式管理介面的 LUA 變體 (FMI) 進行通訊。 (如需詳細資訊，請參閱 FMI 概念.)

  • 指定非強制或強制開啟的指標。 這會判斷如果本機節點目前不是使用中，是否嘗試啟用 SSCP 會話。

    Open (SSCP) 要求可能會因為數個原因之一而失敗，這可以從傳送至應用程式的Open (SSCP) 回應錯誤碼中判斷，如下列清單所述：

  • 本機節點可能仍在初始化 (從組態檔擷取資訊) 。 在此情況下，應用程式可以立即重試。

  • 組態檔可能沒有應用程式的專案，或組態檔中的應用程式記錄可能不會指向 LU 或 LU 群組記錄。

  • 針對非強制的 Open，SSCP 會話可能處於非作用中狀態。