TCP 增強接聽程式訊息連結

  • 發行項

TCP 增強式接聽程式訊息 (ELM) Link 模型允許使用 COMMAREA 在 TI 與伺服器 TP 之間傳遞資料和參數。 此模型也允許並行伺服器連結至 CICS DPL 程式。 增強的接聽程式是在 CICS 交易伺服器 1.4 版中引進，其架構會藉由消除 TRM 和 TRM 回復順序序列來提升 CICS TCP/IP 環境的效率。 增強的接聽程式會接受初始資料流程中用戶端的標頭和要求資料，並不需要伺服器應用程式在應用程式資料可供使用之前傳遞個別的回應。 增強的接聽程式需要用戶端：

  • 建構並傳送由要求標頭組成的單一資料流程，後面接著應用程式要求資料至伺服器應用程式程式

  • 接收單一資料流程，其中包含來自伺服器應用程式程式的回復標頭和應用程式資料

    下圖摘要說明用戶端、增強的 CICS 接聽程式、並行伺服器和大型主機交易程式之間發生的工作流程。 括弧中的數位會指出事件發生的近似順序。 更詳細的事件描述會遵循此圖。

    顯示用戶端、增強的 CICS 接聽程式、並行伺服器和大型主機交易程式之間發生工作流程的影像。

TCP ELM Link 程式設計模型的運作方式如下：

  1. 應用程式會在元件服務或.NET Framework中設定的 TI 元件中叫用方法。

  2. TI 執行時間會呼叫 TI 自動化 Proxy。

  3. 如果應用程式是 COM+ 元件，TI 自動化 Proxy：

    1. 在 TI 先前建立的型別程式庫中讀取 Designer

    2. 將自動化資料類型對應至 COBOL 資料類型

      如果應用程式是.NET Framework元件，TI 自動化 Proxy：

    3. 讀取 TI 先前建立的元件和中繼資料Designer

    4. 將.NET Framework資料類型對應至 COBOL 資料類型

      TI 自動化 Proxy 接著：

    5. 呼叫轉換常式，將應用程式資料轉換成大型主機 COBOL 類型

    6. 會建置代表 COBOL 宣告或 copybook 的扁平化資料流程緩衝區。

    7. 將訊息傳遞至 TCP 傳輸元件。

  4. TI TCP 傳輸會使用大型主機電腦的網際網路通訊協定 (IP) 位址和接聽程式的埠位址，將連線要求傳送至增強接聽程式。

  5. 增強的接聽程式會接受連線要求，並告知 TI 執行時間傳送 ELM。 然後，增強的接聽程式會等候 ELM。

    ELM 是格式化的資料記錄，可識別要使用其 TRANID 叫用的伺服器 TP。 接聽程式 TP 是特殊的大型主機 TP，其主要功能是接收執行 TCP/IP 之用戶端應用程式所傳送的伺服器 TP 調用。 IBM 提供的增強式接聽程式 TP 的 TRANID 是由使用者所定義。

  6. TI 執行時間會格式化 ELM，並將其傳送至增強的接聽程式。 TI 接著會略過等候 ELM 回復的傳輸邏輯，並在要求標頭之後立即傳送應用程式要求資料。 TI 接著會等候 ELM 回復。

  7. 增強的接聽程式會收到 35 位元組 ELM，然後讀取 ELM 標頭的內容。 增強的接聽程式會將 35 個位元組放在交易初始訊息中， (TIM) 但不會在其內容上運作。

    TIM 描述伺服器執行所在的 TCP/IP 環境，並包含並行伺服器用來與 COMTI TCP 傳輸通訊的 TCP/IP 通訊端資訊，以及並行伺服器用來自訂其執行行為的用戶端訊息標頭。 標頭包含要連結的伺服器程式名稱。

  8. 增強的接聽程式會在接聽程式定義中定義的並行伺服器 TP 程式 (mscmtics.cbl 範例應用程式) 啟動。

    Mscmtics.cbl 是 Microsoft 範例 TP 檔案，可用來使用 COMMAREA 在 TI 與伺服器 TP 之間傳遞資料。 Mscmtics.cbl 範例 TP 是由 Microsoft 所開發，並作為主機整合伺服器軟體的一部分提供。 它位於 $\Microsoft Host Integration Server\SDK\Samples\Comti\ProgrammingSpecifics\Tcp 中。 它必須先編譯、連結，並安裝在大型主機電腦上，再使用此模型。

    注意

    如果增強的接聽程式無法啟動並行伺服器，接聽程式會格式化錯誤訊息，並將它傳回 COMTI TCP 傳輸。 接聽程式可能無法啟動的原因包括：

    • 例如，因為 CICS 資源有限 (而拒絕連線，例如，超過 CICS 工作數目上限或並行伺服器工作)

    • 並行伺服器的無效或停用 TRANID

    • 無效、停用或無法使用與交易識別碼相關聯的並行伺服器程式

    注意

    CICS 接聽程式的錯誤訊息是以字元為基礎，且一律以 EZY 字母開頭。 錯誤訊息的長度是可變的，而訊息結尾是由 CICS 接聽程式所關閉的通訊端所決定。

  9. 增強的接聽程式會在主機環境中呼叫通訊端應用程式通訊協定介面 (API) 。 增強的接聽程式發出並行伺服器交易的 start 命令之後，增強的接聽程式就不在應用程式處理迴圈中，而且可以接聽另一個傳入要求。

  10. 並行伺服器會擷取 TIM、連接通訊端，並讀取 ELM 的內容。

  11. TI 會透過 CICS 逗號REA 將應用程式資料傳遞至伺服器應用程式程式，其中包含使用標準 EXEC CICS Link 呼叫的商務邏輯。 TI 執行時間也會針對傳送的 1/2 通訊端發出關機，然後等候回復資料。

  12. 伺服器 TP 會接收應用程式資料、處理要求，以及對資料執行商務邏輯。 所有商務邏輯都會定義于伺服器 TP 中。

  13. 並行伺服器會透過逗號REA 將 ELM 回復標頭傳送至 TI。

  14. 伺服器 TP 會準備回復資料，然後透過 COMMAREA 將回應傳送給用戶端。

  15. 應用程式回復資料流程包含兩個部分。 第一個是 ELM 回復，通知傳輸要求成功或失敗。 TCP 傳輸會從資料流程取用 ELM 回復，然後，如果 ELM 回復指出呼叫成功，請接收應用程式回復資料，直到並行伺服器關閉通訊端為止。

  16. 並行伺服器會關閉通訊端

  17. TI 自動化 Proxy 會接收回複數據並處理回復。 TI 自動化 Proxy：

    1. 從 TCP 傳輸元件接收訊息。

    2. 讀取訊息緩衝區。

      如果應用程式是 COM+ 元件，TI 自動化 Proxy：

    3. 將 COBOL 資料類型對應至自動化資料。

    4. 呼叫轉換常式，將大型主機 COBOL 類型轉換成應用程式資料。

      如果應用程式是 .NET 元件，TI 自動化 Proxy：

    5. 將 COBOL 資料類型對應至.NET Framework資料類型。

    6. 呼叫轉換常式，將大型主機 COBOL 類型轉換成應用程式資料。

  18. TI 執行時間會將已轉換的資料傳回 COM 或.NET Framework叫用 方法的應用程式。

    若要實作此模型，您必須提供 TI 的 IP 位址、埠號碼和 CICS 程式名稱，以執行並行伺服器程式所傳遞的應用程式 (Mscmtics.cbl) 。

    主機整合伺服器包含示範如何實作 TCP ELM Link 程式設計模型的範例程式碼。 範例程式碼位於 \installation directory\SDK\Samples\AppInt。 啟動 Microsoft Visual Studio，開啟您選擇的教學課程，並遵循讀我檔案中的指示。

另請參閱

交易整合器元件
交易要求訊息
將資料類型從自動化轉換為 z/OS COBOL]
將資料類型從 z/OS COBOL 轉換為自動化
CICS 元件
TI 執行階段
選擇適當的程式設計模型
程式設計模型