AWS Mainframe Modernization Service （受管執行期環境體驗） 不再向新客戶開放。對於與 AWS Mainframe Modernization Service （受管執行期環境體驗） 類似的功能，探索 AWS Mainframe Modernization Service （自我管理體驗）。現有客戶可以繼續正常使用該服務。如需詳細資訊，請參閱AWS 大型主機現代化可用性變更。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

AWS 現代化應用程式大型主機結構的轉換

本文件提供有關現代化應用程式結構的詳細資訊 （使用 AWS 大型主機現代化重構工具），以便開發人員可以完成各種任務，例如：

我們假設您已具備下列基本知識：

成品組織

AWS 大型主機現代化應用程式的轉換會封裝為 java Web 應用程式 (.war)，您可以在 JEE 伺服器上部署。一般而言，伺服器是 Tomcat 執行個體，內嵌大型主機執行期的 AWS 轉換，目前建置在 Springboot 和 Angular （適用於 UI 部分） 架構上。

戰會彙總數個元件成品 (.jar)。每個 jar 都是專用 Java 專案的編譯結果 （使用 maven 工具），其元素是現代化程序的結果。

基本組織依賴下列結構：

實體專案內容

在任何重構之前，實體專案中的套件組織會與現代化程式繫結。您可以用幾種不同的方式來完成此操作。偏好的方式是使用重構工具箱，其會在您觸發程式碼產生機制之前運作。這是進階操作，在適用於大型主機訓練的 AWS 轉換中說明。如需詳細資訊，請參閱重構研討會。此方法可讓您保留稍後重新產生 Java 程式碼的功能，以受益於未來的進一步改善，例如）。另一種方法是使用您可能想要套用的任何 Java 重構方法，直接在產生的原始程式碼上執行定期 Java 重構，風險由您自行承擔。

程式相關類別

每個現代化計劃都與兩個套件相關：Business.context 和 business.model 套件。

所有類別都會擴展 RecordEntity類別，代表對業務記錄表示法的存取。有些記錄具有特殊用途，因為它們繫結至 File。在建立檔案物件時，File會在內容類別中找到的對應 *FileHandler 方法中建立 Record和 之間的繫結。例如，以下清單顯示 TransactfileFile File 如何繫結至 transactFile Record（從模型子套件）。

服務專案內容

每個服務專案都隨附專用的 Springboot 應用程式，做為架構的骨幹。這是透過名為 的類別具體化SpringBootLauncher，位於服務 Java 來源的基本套件中：

此類別明顯負責：

程式相關成品

若未事先重構，業務邏輯現代化輸出會依每個舊版程式的兩個或三個套件進行組織：

最詳盡的案例將包含三個套件：

此外，名為 的套件base package.program會扮演重要角色，因為它會為每個程式收集一個類別，做為程式進入點 （稍後對此有更多詳細資訊）。每個類別都會實作Program界面，即程式進入點的標記。

其他成品

公用程式專案內容

公用程式專案的名稱以「工具」結尾，包含一組技術公用程式，可供所有其他專案使用。

Web 專案 （多個） 內容

Web 專案只有在現代化舊版 UI 元素時才存在。用來建置現代化應用程式的現代 UI 元素是以 Angular 為基礎。用來顯示現代化成品的範例應用程式是在大型主機上執行的 COBOL/CICS 應用程式。CICS 系統使用 MAPs 來代表 UI 畫面。對於每個映射，對應的現代元素將是 html 檔案，並隨附 Typescript 檔案：

Web 專案僅負責應用程式的前端方面。依賴 公用程式和實體專案的服務專案提供後端服務。前端和後端之間的連結是透過名為 Gapwalk-Application 的 Web 應用程式建立，這是大型主機執行期分佈標準 AWS 轉換的一部分。

執行和呼叫程式

在舊版系統上，程式會編譯為獨立的可執行檔，可透過 COBOL CALL 陳述式等 CALL 機制呼叫自己，並在需要時傳遞引數。現代化應用程式提供相同的功能，但使用不同的方法，因為涉及成品的性質與舊版成品不同。

在現代化方面，程式進入點是實作Program界面的特定類別，是 Spring 元件 (@Component)，位於名為 的套件中的服務專案中base package.program。

程式註冊

每次啟動託管現代化應用程式的 Tomcat 伺服器時，也會啟動服務 Springboot 應用程式，這會觸發程式註冊。名為 的專用登錄ProgramRegistry檔會填入程式項目，每個使用其識別符註冊的程式，每個已知程式識別符各一個項目，這表示如果程式是由數個不同的識別符所知道，登錄檔會包含任意數量的項目，其中有識別符。

指定程式的註冊依賴於 getProgramIdentifiers() 方法傳回的識別符集合：

在此範例中，程式註冊一次，名稱為 'CBACT04C' （查看 programIdentifiers 集合的內容）。tomcat 日誌會顯示每個程式註冊。程式註冊僅取決於宣告的程式識別符，而非程式類別名稱本身 （雖然通常符合程式識別符和程式類別名稱。

相同的註冊機制適用於大型主機 Web 應用程式的各種公用程式 AWS Transform 帶來的公用程式程式，這是大型主機執行期分佈 AWS 的 Transform 的一部分。例如，Gapwalk-Utility-Pgm Webapp 提供 z/OS 系統公用程式 (IDCAMS、ICEGENER、SORT 等） 的功能對等項目，並且可由現代化程式或指令碼呼叫。在 Tomcat 啟動時註冊的所有可用公用程式都會記錄在 Tomcat 日誌中。

指令碼和協助程式註冊

在 Tomcat 啟動時間，位於 /src/main/resources/scripts 資料夾階層的 groovy 指令碼會發生類似的註冊程序。指令碼資料夾階層會周遊，而探索到的所有 groovy 指令碼 （特殊 function.groovy 預留指令碼除外） 會使用其簡短名稱 （指令碼檔案名稱的一部分，位於第一個點字元之前） 做為擷取金鑰ScriptRegistry，在 中註冊。

/src/main/resources/daemons 資料夾中的 groovy 指令碼處理方式略有不同。它們仍然註冊為一般指令碼，但此外，它們會在 Tomcat 啟動時間以非同步方式直接啟動一次。

在 中註冊指令碼後ScriptRegistry，REST 呼叫可以使用 Gapwalk-Application 公開的專用端點來啟動它們。如需詳細資訊，請參閱對應的文件。

呼叫程式的程式

每個程式都可以呼叫另一個程式做為子程式，並將參數傳遞給它。程式會使用 ExecutionController 界面的實作來執行此操作 （大多數時候，這會是ExecutionControllerImpl執行個體），以及名為 的流暢 API 機制CallBuilder來建置程式呼叫引數。

所有程式方法都採用 RuntimeContext和 ExecutionController作為方法引數，因此 ExecutionController 一律可用於呼叫其他程式。

例如，請參閱下圖，其中顯示 CBST03A 程式如何將 CBST03B 程式呼叫為子程式，並將參數傳遞給程式：

這三個引數都是強制性的，不能是 null，但第二個引數可以是空的陣列。

只有在原本設計時，受話方才能處理傳遞的參數。對於舊版 COBOL 程式，這表示具有 LINKAGE 區段和 USING 子句，讓程序分區使用 LINKAGE 元素。

例如，請參閱對應的 CBSTM03B.CBL COBOL 來源檔案：

因此，CBSTM03B 程式採用單一 Record做為參數 （大小為 1 的陣列）。這是 CallBuilder 所建置的內容，使用 byReference() 和 getArguments() 方法鏈結。

CallBuilder 流暢的 API 類別有數種方法可用來填入要傳遞給受話方的引數陣列：

最後，getArguments 方法會收集所有新增的引數，並以 陣列傳回這些引數Record。

指令碼呼叫程式

從 groovy 指令碼呼叫已註冊的程式需要使用實作MainProgramRunner界面的類別執行個體。通常，透過 Spring 的 ApplicationContext 使用方式來取得這類執行個體：

在MainProgramRunner介面可用後，使用 runProgram 方法呼叫程式，並將目標程式的識別符做為參數傳遞：

在先前的範例中，任務步驟會呼叫 IDCAMS （檔案處理公用程式程式），提供實際資料集定義與其邏輯識別符之間的映射。

處理資料集時，舊版程式大多使用邏輯名稱來識別資料集。從指令碼呼叫程式時，指令碼必須對應邏輯名稱與實際的實體資料集。這些資料集可能位於檔案系統、Blusam 儲存體中，甚至由內嵌串流定義、串連數個資料集，或產生 GDG。

使用 withFileConfiguration 方法來建置邏輯到資料集的實體映射，並將其提供給呼叫的程式。

撰寫您自己的程式

為指令碼或其他現代化程式撰寫自己的程式來呼叫 是常見的任務。一般而言，在現代化專案中，當可執行式舊版程式以現代化程序不支援的語言撰寫，或來源已遺失 （是，可能會發生這種情況），或程式是無法使用來源的公用程式時，您會撰寫自己的程式。

在這種情況下，您可能必須自行在 Java 中撰寫缺少的程式 （假設您對程式預期的行為、程式引數的記憶體配置有的話，以此類推）。您的 Java 程式必須符合本文件所述的程式機制，以便其他程式和指令碼可以執行它。

若要確保程式可供使用，您必須完成兩個必要步驟：

撰寫程式實作

使用您的 IDE 來建立新的 Java 類別，以實作Program界面：

下圖顯示 Eclipse IDE，負責建立要實作的所有強制性方法：

彈簧整合

首先，必須將 類別宣告為 Spring 元件。使用 註釋來註釋 類別@Component：

接著，正確實作所需的方法。在此範例內容中，我們將 MyUtilityProgram 新增至已包含所有現代化程式的套件。該置放允許程式使用現有的 Springboot 應用程式來提供 getSpringApplication 方法實作ConfigurableApplicationContext所需的 ：

您可以為自己的程式選擇不同的位置。例如，您可以在另一個專用服務專案中找到指定的程式。確定指定的服務專案有自己的 Springboot 應用程式，這可讓您擷取 ApplicationContext （應該是 ConfigurableApplicationContext)。

將身分提供給程式

若要讓其他程式和指令碼呼叫，程式必須至少提供一個識別符，這不得與系統中任何其他現有的已註冊程式衝突。識別符選擇可能是由需要涵蓋現有舊版程式取代所驅動；在這種情況下，您必須使用預期的識別符，如同在舊版程式中發現的 CALL 出現次數一樣。在舊版系統中，大多數的程式識別符長度為 8 個字元。

在程式中建立一組無法修改的識別符是執行此操作的一種方式。下列範例顯示選擇「MYUTILPG」作為單一識別符：

將程式與內容建立關聯

程式需要配套RuntimeContext執行個體。對於現代化程式，適用於大型主機的 AWS Transform 會使用屬於舊版程式的資料結構，自動產生配套內容。

如果您要撰寫自己的程式，您也必須撰寫配套內容。

參考 程式相關類別，您可以看到程式至少需要兩個配套類別：

如果公用程式程式使用任何額外的資料結構，則應一併寫入並供內容使用。

這些類別應位於套件中，該套件包含在應用程式啟動時掃描的套件階層中，以確保內容元件和組態將由 Spring 架構處理。

讓我們在base package.myutilityprogram.business.context套件中撰寫在實體專案中新建立的最小組態和內容：

以下是組態內容。它使用的組態組建類似於附近的其他 -- 現代化 -- 程式。您可能必須根據您的特定需求自訂此項目。

備註：

以及相關聯的內容：

備註

現在有可用的專用內容，讓新程式使用它：

備註：

實作商業邏輯

當程式骨架完成時，請實作新公用程式的商業邏輯。

在程式的 run方法中執行此操作。此方法會在呼叫程式時執行，無論是透過其他程式或指令碼。

編碼愉快！

處理程式註冊

最後，請確定新的程式已在 中正確註冊ProgramRegistry。如果您已將新程式新增至已包含其他程式的套件，則無需再執行任何操作。新程式會在應用程式啟動時取得並註冊其所有鄰近程式。

如果您為程式選擇其他位置，則必須確保程式已在 Tomcat 啟動時正確註冊。如需有關如何執行此操作的一些啟發，請查看服務專案中產生之 SpringbootLauncher 類別的初始化方法 （請參閱服務專案內容)。

檢查 Tomcat 啟動日誌。每個程式註冊都會記錄。如果您的程式已成功註冊，您會找到相符的日誌項目。

當您確定您的程式已正確註冊時，您可以開始反覆運算商業邏輯編碼。

完整名稱映射

本節包含大型主機 AWS 轉換的清單，以及用於現代化應用程式的第三方完整名稱映射。

AWS 大型主機完整名稱映射的轉換

第三方完整名稱映射