AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) は、新規のお客様に公開されなくなりました。 AWS Mainframe Modernization Service (マネージドランタイム環境エクスペリエンス) と同様の機能については、 AWS Mainframe Modernization Service (セルフマネージドエクスペリエンス) をご覧ください。既存のお客様は、通常どおりサービスを引き続き使用できます。詳細については、[AWS 「 Mainframe Modernization の可用性の変更](https://docs.aws.amazon.com/m2/latest/userguide/mainframe-modernization-availability-change.html)」を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS モダナイズされたアプリケーションのメインフレーム構造の変換
このドキュメントでは、開発者が次のようなさまざまなタスクを実行できるように、モダナイズされたアプリケーションの構造 ( AWS Mainframe Modernization リファクタリングツールを使用) について詳しく説明します。
+ アプリケーションへのスムーズなナビゲーション。
+ モダナイズされたアプリケーションから呼び出せるカスタムプログラムの開発。
+ モダナイズされたアプリケーションの安全なリファクタリング。
次の内容に関する基本的な知識を既に保持していることを前提としています。
+ レコード、データセット、レコードへのアクセスモード (インデックス付き、シーケンシャル)、VSAM、実行ユニット、jcl スクリプト、CICS 概念など、従来の共通コーディング概念。
+ [Spring フレームワーク](https://spring.io/projects/spring-framework)を使用した Java コーディング。
+ ドキュメント全体をとおして、読みやすさを考慮して `short class names` を使用しています。詳細については、[AWS メインフレーム完全修飾名マッピングの変換](#ba-shared-structure-fqn-table)「」を参照してメインフレームランタイム要素の AWS 変換に対応する完全修飾名を取得し、[サードパーティーの完全修飾名マッピング](#ba-shared-structure-3pfqn-table)「」を参照してサードパーティ要素に対応する完全修飾名を取得します。
+ すべてのアーティファクトとサンプルは、COBOL/CICS [CardDemo アプリケーション](https://github.com/aws-samples/aws-mainframe-modernization-carddemo)サンプルのモダナイゼーションプロセス出力から取得されます。
**Topics**
+ [アーティファクトの組織](#ba-shared-structure-org)
+ [プログラムの実行と呼び出し](#ba-shared-structure-run-call)
+ [独自のプログラムの作成](#ba-shared-structure-write)
+ [完全修飾名マッピング](#ba-shared-structure-fqn)
## アーティファクトの組織
AWS メインフレームのモダナイズされたアプリケーションの変換は、JEE サーバーにデプロイできる java ウェブアプリケーション (.war) としてパッケージ化されます。通常、サーバーはメインフレームランタイムの AWS 変換を埋め込む [Tomcat](https://tomcat.apache.org/) インスタンスであり、現在 [Springboot](https://spring.io/projects/spring-boot) フレームワークと [Angular](https://angular.io/) (UI パート用) フレームワーク上に構築されています。
war は複数のコンポーネントアーティファクト (.jar) を統合します。各 jar は専用の Java プロジェクトを ([maven](https://maven.apache.org/) ツールを使用して) コンパイルして生成され、その要素はモダナイズプロセスの結果生じます。
![\[モダナイズアプリケーションアーティファクトのサンプル。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/modernized_application_artifacts.png)
基本的な組織は以下の構造に基づいています。
+ エンティティプロジェクト: ビジネスモデルとコンテキスト要素が含まれます。プロジェクト名は通常「-entities」で終わります。通常は、レガシー COBOL プログラムであると仮定すると、これは I/O セクション (データセット) とデータ部のモダナイズに相当します。複数のエンティティプロジェクトを使用することができます。
+ サービスプロジェクト: レガシービジネスロジックのモダナイズ要素が含まれています。通常は COBOL プログラムの手続き部です。複数のサービスプロジェクトを使用することもできます。
+ ユーティリティプロジェクト: 他のプロジェクトで使用されている、共通のツールやユーティリティが含まれています。
+ ウェブプロジェクト: UI 関連の要素をモダナイズしたもの (該当する場合) が含まれます。バッチのみのモダナイズプロジェクトには使用されません。これらの UI 要素は、CICS BMS マップ、IMS MFS コンポーネント、その他のメインフレーム UI ソースに由来する場合があります。複数のウェブプロジェクトを使用することができます。
### エンティティプロジェクトの内容
**注記**
以下の説明は COBOL と PL/I のモダナイゼーション出力にのみ適用されます。RPG モダナイゼーション出力は異なるレイアウトに基づいています。
リファクタリングを行う前に、エンティティプロジェクトのパッケージ構成をモダナイズプログラムと関連付けます。これを実行するための、いくつか方法があります。推奨される方法は、コード生成メカニズムを起動する前に動作する、リファクタリングツールボックスを使用することです。これは高度なオペレーションであり、メインフレームトレーニングの AWS Transform で説明されています。詳細については、「[リファクタリングワークショップ](https://catalog.workshops.aws/aws-blu-age-l3-certification-workshop/en-US/refactoring)」を参照してください。このアプローチでは後で Java コードを再生成する機能を維持できるため、将来さらに改善できるというメリットがあります。もう 1 つの方法は、自己責任でお好みの Java リファクタリングアプローチを使用して、生成されたソースコードに対して直接、標準の Java リファクタリングを行うことです。
![\[サンプルプログラム CBACT04C のエンティティパッケージ。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/entities_packages.png)
#### プログラム関連クラス
各モダナイズプログラムは、business.context パッケージと business.model パッケージという、2 つのパッケージに関連付けられます。
+ `base package.program.business.context`
business.context サブパッケージには、構成クラスとコンテキストクラスという 2 つのクラスが含まれています。
+ プログラムの 1 つの構成クラスには、文字ベースのデータ要素を表すために使用する文字セット、データ構造要素をパディングするためのデフォルトバイト値など、特定のプログラム固有の構成情報が含まれます。クラス名は「Configuration」で終わります。`@org.springframework.context.annotation.Configuration` アノテーションが付いており、正しくセットアップされた `Configuration` オブジェクトを返す必要がある単一メソッドが含まれています。
![\[Java のサンプル設定。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_configuration.png)
+ 1 つのコンテキストクラスは、プログラムサービスクラス (以下を参照) と、モデルサブパッケージ (以下を参照) のデータ構造 (`Record`) やデータセット (`File`) との間のブリッジとして機能します。クラス名は「Context」で終わり、`RuntimeContext` クラスのサブクラスです。
![\[コンテキストクラス例 (部分ビュー)\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_context.png)
+ `base package.program.business.model`
モデルサブパッケージには、特定のプログラムが使用できるすべてのデータ構造が含まれています。例えば、01 レベルの COBOL データ構造はいずれもモデルサブパッケージ内のクラスに対応します (下位レベルのデータ構造は、それぞれ独自の 01 レベル構造のプロパティです)。01 データ構造をモダナイズする方法については、「[Transform AWS for Mainframe のデータシンプリファイアとは](ba-shared-data.md)」を参照してください。
![\[レコードエンティティ例 (部分ビュー)\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_record_entity.png)
すべてのクラスは、ビジネスレコード表現へのアクセスを表す `RecordEntity` クラスを拡張します。レコードの中には、`File` にバインドされている特別な目的を持つものもあります。`Record` と `File` の間のバインディングは、ファイルオブジェクトの作成時にコンテキストクラスにある、対応する \$1FileHandler メソッドで実行されます。例えば、次のリストは TransactfileFile が `File` が transactFile `Record` に (モデルサブパッケージから) バインドされる方法を示しています。
![\[レコードとファイルのバインディング例。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_record_file_binding.png)
### サービスプロジェクトの内容
すべてのサービスプロジェクトには、アーキテクチャのバックボーンとして使用される、専用の [Springboot](https://spring.io/projects/spring-boot) アプリケーションが付属しています。これは、サービス java ソースのベースパッケージにある、`SpringBootLauncher` という名前のクラスを通じて実現されます。
![\[サービスプロジェクト SpringBoot アプリケーション。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/springbootlauncher.png)
このクラスは特に以下の役割を果たします。
+ プログラムクラスとマネージドリソース (データソース、トランザクションマネージャー、データセットマッピングなど) を結合します。
+ プログラムに `ConfigurableApplicationContext` を提供します。
+ spring コンポーネント (`@Component`) とマークされたクラスをすべて検出します。
+ プログラムが `ProgramRegistry` に正しく登録されていることを確認します。この登録を管理する初期化メソッドを参照してください。
![\[プログラムの登録。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/programs_registration.png)
#### プログラム関連アーティファクト
事前にリファクタリングを行わなくても、ビジネスロジックのモダナイゼーション出力は、レガシープログラムごとに以下の 2 つまたは 3 つのパッケージにまとめられます。
![\[プログラムパッケージ例。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_program_packages.png)
最も包括的なケースには、次の 3 つのパッケージがあります。
+ `base package.program.service`: *Program*Process という名前のインターフェイスが含まれ、これには従来の実行制御フローを維持したままビジネスロジックを処理するビジネスメソッドが含まれています。
+ `base package.program.service.impl`: *Program*ProcessImpl という名前のクラスが含まれ、これは前に説明した Process インターフェイスが実装されたものです。ここでは、メインフレームフレームワークの AWS 変換に依存して、レガシーステートメントが java ステートメントに「変換」されます。
![\[モダナイズされた CICS ステートメント例 (SEND MAP、RECEIVE MAP)\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_cics_statements.png)
+ `base package.program.statemachine`: このパッケージが常にあるとは限りません。レガシー制御フローのモダナイゼーションでステートマシンアプローチを使用 (つまり、[Spring StateMachine フレームワーク](https://spring.io/projects/spring-statemachine)を使用) してレガシー実行フローを適切にカバーしなければならない場合に必要です。
その場合、statemachine サブパッケージには次の 2 つのクラスが含まれます。
+ `ProgramProcedureDivisionStateMachineController`: Spring ステートマシン構造の駆動に使用される `StateMachineController` (ステートマシンの実行の制御に必要な操作を定義) インターフェイスと `StateMachineRunner` (ステートマシンの実行に必須の操作を定義) インターフェイスを実装しているクラスを拡張するクラス (ケース例の `SimpleStateMachineController` など)。
![\[サンプルステートマシンコントローラ。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_statemachine_controller.png)
ステートマシンコントローラは、発生する可能性のあるさまざまな状態、およびそれらの間の遷移を定義します。これにより、特定のプログラムの従来の実行制御フローが再現されます。
ステートマシンを構築する際、コントローラはステートマシンパッケージ内の関連するサービスクラスで定義されているメソッドを参照します。以下で説明します。
```
subConfigurer.state(States._0000_MAIN, buildAction(() -> {stateProcess._0000Main(lctx, ctrl);}), null);
subConfigurer.state(States.ABEND_ROUTINE, buildAction(() -> {stateProcess.abendRoutine(lctx, ctrl);}), null);
```
+ `ProgramProcedureDivisionStateMachineService`: このサービスクラスは、前述のように、ステートマシンコントローラが作成するステートマシンにバインドする必要のある、一部のビジネスロジックを表します。
このクラスのメソッド内のコードは、ステートマシンコントローラで定義された以下のイベントを使用します。
![\[ステートマシンコントローライベントを使用するステートマシンサービス。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/service_using_event_1.png)
![\[ステートマシンコントローライベントを使用するステートマシンサービス。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/service_using_event_2.png)
また、ステートマシンサービスは、以前説明した以下のプロセスサービス実装を呼び出します。
![\[プロセス実装への呼び出しを実行する .statemachine サービス\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/service_using_processimpl.png)
それに加えて、`base package.program` という名前のパッケージは、プログラムごとにプログラムのエントリポイントとなる 1 つのクラスを集めるという、重要な役割を果たします (これについては後で詳しく説明します)。各クラスはプログラムのエントリポイントのマーカーである `Program` インターフェイスを実装しています。
![\[プログラムエントリポイント\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/programs.png)
#### その他のアーティファクト
+ BMS MAP コンパニオン
プログラム関連のアーティファクトに加えて、サービスプロジェクトにはさまざまな目的のアーティファクトを含めることができます。CICS オンラインアプリケーションをモダナイズする場合、モダナイゼーションプロセスでは json ファイルが生成され、/src/main/resources フォルダの map フォルダに格納されます。
![\[リソースフォルダの BMS MAP JSON ファイル。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/maps_json_files.png)
AWS Transform for mainframe ランタイムは、これらの JSON ファイルを使用して、SEND MAP ステートメントで使用されるレコードを画面フィールドでバインドします。
+ Groovy スクリプト
レガシーアプリケーションに JCL スクリプトがあった場合、それらは [groovy](https://groovy-lang.org/) スクリプトとしてモダナイズされ、/src/main/resources/scripts フォルダに保存されます (この特定の場所については後で詳しく説明します)。
![\[groovy スクリプト (JCL モダナイゼーション)\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/groovy_scripts.png)
これらのスクリプトは、バッチジョブ (専用の、インタラクティブではない、CPU 負荷の高いデータ処理ワークロード) を起動するために使用されます。
+ SQL ファイル
レガシーアプリケーションが SQL クエリを使用していた場合、対応するモダナイズ SQL クエリは、*program*.sql という命名パターンを持つ専用のプロパティファイルにまとめられています。ここで、*program* は、そのクエリを使用するプログラムの名前です。
![\[リソースフォルダの SQL ファイル\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sql_files.png)
これらの sql ファイルの内容は (key=query) エントリの集合で、各クエリは固有のキーに関連付けられており、モダナイズプログラムはこれを使用して特定のクエリを実行します。
![\[モダナイズされたプログラムが使用する sql サンプルファイル。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_sql_file.png)
例えば、COSGN00C プログラムは「COSGN00C\$11」(sql ファイルの最初のエントリ) というキーを使用してクエリを実行します。
![\[プログラム別のクエリ使用例\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_sql_query_usage.png)
### ユーティリティプロジェクトの内容
名前が「-tools」で終わるユーティリティプロジェクトには、他のすべてのプロジェクトで使用できるテクニカルユーティリティのセットが含まれています。
![\[ユーティリティプロジェクトの内容\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/tools_project.png)
### ウェブプロジェクトの内容
ウェブプロジェクトはレガシー UI 要素をモダナイズする場合にのみ存在します。モダナイズされたアプリケーションのフロントエンドの構築に使用されるモダン UI 要素は [Angular](https://angular.io/) に基づいています。モダナイゼーションアーティファクトを示すために使用されるアプリケーション例は、メインフレーム上で実行される COBOL/CICS アプリケーションです。CICS システムは MAP を使用して UI 画面を表します。すべてのマップにおいて、対応するモダン要素は [Typescript](https://www.typescriptlang.org/) ファイルを伴った HTML ファイルになります。
![\[Angular にモダナイズされた CICS マップ例\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_cics_maps_angular.png)
ウェブプロジェクトはアプリケーションのフロントエンド部分のみを処理します。ユーティリティプロジェクトとエンティティプロジェクトに依存するサービスプロジェクトは、バックエンドサービスを提供します。フロントエンドとバックエンド間のリンクは、メインフレームランタイムディストリビューションの標準 AWS 変換の一部である Gapwalk-Application という名前のウェブアプリケーションを介して行われます。
## プログラムの実行と呼び出し
レガシーシステムでは、プログラムはスタンドアロンの実行ファイルとしてコンパイルされ、COBOL CALL ステートメントなどの CALL メカニズムを通じて自らを呼び出し、必要に応じて引数を渡すことができます。モダナイズされたアプリケーションでも機能は同じですが、関連するアーティファクトの性質が従来のものとは異なるため、別のアプローチを使用します。
モダナイズされた側では、プログラムのエントリポイントは `Program` インターフェイスを実装する特定のクラス、Spring コンポーネント (@Component) であり、サービスプロジェクト内の `base package.program` という名前のパッケージにあります。
### プログラムの登録
モダナイズされたアプリケーションをホストする [Tomcat](https://tomcat.apache.org/) サーバーが起動するたびに、サービス Springboot アプリケーションも起動し、これによりプログラムの登録が開始されます。`ProgramRegistry` という名前の専用レジストリにはプログラムエントリが格納され、各プログラムは既知のプログラム ID につき 1 つのエントリを使用して登録されます。つまり、プログラムが複数の異なる識別子で認識されている場合、レジストリには識別子と同じ数のエントリが含まれます。
特定のプログラムの登録は、getProgramIdentifiers() メソッドによって返される識別子のコレクションに依存します。
![\[プログラム例 (部分ビュー)\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/sample_program.png)
この例では、プログラムは 'CBACT04C' という名前で 1 回登録されています (programIdentifiers コレクションの内容を見てください)。tomcat のログには、すべてのプログラムの登録が表示されます。プログラム登録は宣言されたプログラム ID にのみ依存し、プログラムクラス名自体には依存しません (ただし、通常、プログラム ID とプログラムクラス名は一致しています)。
メインフレームランタイムディストリビューションの AWS 変換の一部であるメインフレームウェブアプリケーションのさまざまなユーティリティ AWS 変換によって提供されるユーティリティプログラムにも同じ登録メカニズムが適用されます。例えば、Gapwalk-Utility-Pgm ウェブアプリは z/OS システムユーティリティ (IDCAMS、ICEGENER、SORT など) と同等の機能を備えており、モダナイズされたプログラムやスクリプトから呼び出すことができます。Tomcat のスタートアップ時に登録された利用可能なユーティリティプログラムはすべて Tomcat ログに記録されます。
### スクリプトとデーモンの登録
/src/main/resources/scripts フォルダ階層にある groovy スクリプトでも、同様の登録プロセスが Tomcat のスタートアップ時に行われます。scripts フォルダ階層がトラバースされ、見つかったすべての groovy スクリプト (特別な functions.groovy 予約スクリプトを除く) が、そのショートネーム (スクリプトファイル名の最初のドット文字の前にある部分) を取得用キーとして使用して `ScriptRegistry` に登録されます。
**注記**
複数のスクリプトのファイル名を使用して同じ登録キーが生成される場合、最後のものだけが登録され、そのキーに対して以前に登録されたものは上書きされます。
登録メカニズムによって階層は平坦になり、予期しない上書きが発生する可能性があるため、サブフォルダを使用する場合は上記の点を考慮してご注意ください。階層は登録プロセスでは考慮されません。通常 /scripts/A/myscript.groovy と /scripts/B/myscript.groovy の順に生成されると /scripts/B/myscript.groovy により /scripts/A/myscript.groovy が上書きされます。
/src/main/resources/daemons フォルダにある groovy スクリプトの扱いは少し異なります。これらは通常のスクリプトとして登録されていますが、それに加えて、Tomcat のスタートアップ時に一度だけ非同期的に直接起動されます。
スクリプトが `ScriptRegistry` に登録されると、Gapwalk-Application が公開する専用のエンドポイントを使用して REST を呼び出すとスクリプトを起動できます。詳細については、対応するドキュメントをご参照ください。
### プログラム呼び出しプログラム
各プログラムは他のプログラムをサブプログラムとして呼び出し、パラメータを渡すことができます。プログラムは、`ExecutionController` インターフェイスの実装を使用し (ほとんどの場合、これは `ExecutionControllerImpl` インスタンスです)、`CallBuilder` という fluent API メカニズムと連動してプログラム呼び出し引数を構築します。
すべてのプログラムのメソッドは `RuntimeContext` と `ExecutionController` の両方をメソッド引数と解釈するため、`ExecutionController` は常に他のプログラムを呼び出すことができます。
例えば、CBST03A プログラムが CBST03B プログラムをサブプログラムとして呼び出し、パラメータを渡す方法を示す次の図を参照してください。
![\[.sub-program の呼び出し例\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/subprogram_call_sample.png)
+ `ExecutionController.callSubProgram` の最初の引数は、呼び出すプログラムの識別子です (つまり、プログラム登録に使用される識別子のうちの 1 つです。上の段落を参照してください)。
+ 2 番目の引数は、`CallBuilder` をビルドした結果で、呼び出し元から呼び出し先に渡されたデータに対応する `Record` の配列です。
+ 3 番目の、最後の引数は呼び出し元の `RuntimeContext` インスタンスです。
3 つの引数はすべて必須で NULL にできませんが、2 番目の引数は空の配列でも構いません。
呼び出し先が渡されたパラメータを処理できるのは、元々そのように設計されていた場合のみです。レガシー COBOL プログラムでは、LINKAGE 要素を利用するため、手続き部に LINKAGE 節と USING 句が必要です。
例えば、対応する [CBSTM03B.CBL](https://github.com/aws-samples/aws-mainframe-modernization-carddemo/blob/main/app/cbl/CBSTM03B.CBL) COBOL ソースファイルを参照してください。
![\[COBOL ソースファイルのサンプルリンク\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/linkage_sample.png)
そのため、CBSTM03B プログラムはパラメータ (サイズ 1 の配列) として単一 `Record` を取ります。これこそが、`CallBuilder` が byReference() メソッドと getArguments() メソッド連鎖を使って構築しているものです。
`CallBuilder` fluent API クラスには、呼び出し先に渡す引数の配列を投入するためのメソッドがいくつか用意されています。
+ asPointer(RecordAdaptable): 参照ごとに、ポインタ型の引数を追加します。ポインタは対象となるデータ構造のアドレスを表します。
+ byReference(RecordAdaptable): 参照ごとに引数を追加します。呼び出し側は呼び出し先が実行する変更を確認します。
+ byReference(RecordAdaptable): 前のメソッドの varargs バリアント。
+ byValue(Object): `Record` に変換された引数を、値ごとに追加します。呼び出し側は呼び出し先が実行する変更を確認しません。
+ byValue(RecordAdaptable): 前のメソッドと同じですが、引数は `RecordAdaptable` として直接使用できます。
+ byValueWithBounds(Object, int, int): 値ごとに、引数を追加して `Record` に変換し、指定された範囲で定義されているバイト配列部分を抽出します。
最後に、getArguments メソッドは追加された引数をすべて収集し、`Record` の配列として返します。
**注記**
呼び出し元は、引数の配列が必要なサイズであること、項目が適切に順序付けられており、リンケージ要素で想定されるレイアウトとメモリレイアウトに関し互換性があることを確認する責任があります。
### スクリプト呼び出しプログラム
登録済みプログラムを groovy スクリプトから呼び出すには、その `MainProgramRunner` インターフェイスを実装するクラスインスタンスを使用する必要があります。通常、このようなインスタンスを取得するには Spring の以下の ApplicationContext を使用します。
![\[.MainProgramRunner: インスタンスの取得\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/mpr.png)
`MainProgramRunner` インターフェイスが使用可能になったら、runProgram メソッドを使用してプログラムを呼び出し、ターゲットプログラムの識別子をパラメータとして渡します。
![\[MainProgramRunner: プログラムの実行\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/mpr_runprogram.png)
前の例では、ジョブステップが IDCAMS (ファイル処理ユーティリティプログラム) を呼び出し、実際のデータセット定義とその論理識別子の間のマッピングを提供します。
データセットを扱う場合、レガシープログラムではたいてい論理名を使用してデータセットを識別します。プログラムをスクリプトから呼び出す場合、スクリプトは論理名と実際の物理データセットとマッピングする必要があります。これらのデータセットは、ファイルシステムや Blusam ストレージに格納されている場合もあれば、インラインストリーム、複数のデータセットの連結、GDG の生成によって定義される場合もあります。
withFileConfiguration メソッドを使用すると、データセットの論理マップと物理マップを構築でき、呼び出されたプログラムで利用できるようになります。
## 独自のプログラムの作成
スクリプト、またはその他のモダナイズされたプログラムを呼び出すために、独自のプログラムを作成するのはよくある作業です。通常、モダナイゼーションプロジェクトでは、実行可能なレガシープログラムがモダナイゼーションプロセスでサポートされていない言語で書かれていたり、ソースが失われた場合 (これは発生する場合があります)、またはプログラムがソースを利用できないユーティリティだったりする場合に、独自のプログラムを作成します。
その場合、足りないプログラムを java で、自分で書かなければならない場合があります (プログラムの期待される動作がどうあるべきか、プログラムの引数のメモリレイアウト (ある場合) などについて十分な知識があることを前提としています)。java プログラムは、他のプログラムやスクリプトで実行できるように、このドキュメントで説明されているプログラムの仕組みに準拠している必要があります。
プログラムが使用に適していることを確認するには、次の 2 つの必須ステップを完了する必要があります。
+ `Program` インターフェイスを正しく実装するクラスを作成して、登録および呼び出すことができるようにしてください。
+ 他のプログラムやスクリプトから見えるようにするため、プログラムを正しく登録してください。
### プログラム実装の記述
IDE を使用して `Program` インターフェイスを実装する新しい java クラスを作成します。
![\[新しい java プログラムクラスの作成\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/new_program.png)
以下の画像は、実装する必須メソッドをすべて作成する Eclipse IDE を示しています。
![\[新しい java プログラムクラスの作成 - ソースの編集\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/new_program_ide.png)
### Spring との統合
まず、クラスを Spring コンポーネントとして宣言する必要があります。クラスに以下の `@Component` アノテーションを付けます。
![\[spring @Component アノテーションの使用\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/program_component.png)
次に、必要なメソッドを正しく実装します。このサンプルのコンテキストでは、モダナイズされたプログラムがすべて含まれているパッケージに `MyUtilityProgram` を追加しました。この配置により、プログラムは既存の Springboot アプリケーションを使用して getSpringApplication メソッドの実装に必要な `ConfigurableApplicationContext` を提供できるようになります。
![\[getSpringApplication メソッドを実装します。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/getSpringApplication.png)
独自のプログラムでは別の場所を選択することもできます。例えば、特定のプログラムを別の専用サービスプロジェクトに配置する場合があります。特定のサービスプロジェクトに、ApplicationContext を取得できるようにするための、独自の Springboot アプリケーションがあることを確認してください (このアプリケーションは `ConfigurableApplicationContext` である必要があります)。
### プログラムに識別子を与える
他のプログラムやスクリプトから呼び出せるようにするには、そのプログラムに少なくとも 1 つの識別子を与える必要があります。その識別子は、システム内の既存の登録済みプログラムと衝突することはできません。識別子は既存のレガシープログラムの代わりとなるものが必要な場合に選択する可能性があります。その場合は、レガシープログラム全体で見られる呼び出し発生回数に応じて要求される識別子を使用する必要があります。レガシーシステムでは、ほとんどのプログラム識別子は 8 文字です。
その 1 つの方法はプログラム内で変更できない識別子のセットを作成することです。次の例は、「MYUTILPG」を単一識別子として選択する方法を示しています。
![\[プログラム識別子の例\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/program_identifier.png)
### プログラムをコンテキストに関連付ける
プログラムにはコンパニオン `RuntimeContext` インスタンスが必要です。モダナイズされたプログラムの場合、 AWS Transform for mainframe はレガシープログラムの一部であるデータ構造を使用してコンパニオンコンテキストを自動的に生成します。
独自のプログラムを作成する場合は、コンパニオンコンテキストも作成する必要があります。
[プログラム関連クラス](#ba-shared-structure-org-entities-program) を参照すると、プログラムには少なくとも以下の 2 つのコンパニオンクラスが必要であることがわかります。
+ 設定クラス。
+ 設定を使用するコンテキストクラス。
ユーティリティプログラムが追加のデータ構造を使用する場合は、そのデータ構造も記述してコンテキストで使用する必要があります。
これらのクラスは、コンテキストのコンポーネントと構成が Spring フレームワークによって処理されるようにするために、アプリケーションのスタートアップ時にスキャンされるパッケージ階層に含める必要があります。
エンティティプロジェクトで新しく作成した `base package.myutilityprogram.business.context` パッケージに、最小限の設定とコンテキストを記述してみましょう。
![\[新しいユーティリティプログラムのための新しい専用設定とコンテキスト\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/new_program_context_package.png)
設定内容は次のとおりです。近くにある他の (モダナイズされた) プログラムと類似した設定ビルドを使っています。おそらく、特定のニーズに合わせてこれをカスタマイズする必要があるでしょう。
![\[新しいプログラムの設定\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/new_program_configuration.png)
注記:
+ 一般的な命名規則は *ProgramName*Configuration です。
+ @org.springframework.context.annotation.Configuration アノテーションと @Lazy アノテーションを使用する必要があります。
+ bean 名は通常 *ProgramName*ContextConfiguration の規則に従いますが、これは必須ではありません。プロジェクト全体で bean 名が競合しないようにしてください。
+ 実装する単一メソッドは `Configuration` オブジェクトを返す必要があります。オブジェクトの構築には `ConfigurationBuilder` fluent API が便利です。
関連するコンテキスト:
![\[Java ファイル内の新しいプログラムコンテキスト。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/new_program_context.png)
注意事項
+ コンテキストクラスは、既存の `Context` インターフェイス実装 (JICS 固有の項目で拡張された `RuntimeContext` である、`RuntimeContext`または`JicsRuntimeContext`) を拡張する必要があります。
+ 一般的な命名規則は *ProgramName*Context です。
+ これをプロトタイプコンポーネントとして宣言し、@Lazy アノテーションを使用する必要があります。
+ コンストラクタは関連付けされた設定を参照し、@Qualifier アノテーションを使って適切な設定クラスをターゲットにします。
+ ユーティリティプログラムがいくつかの追加のデータ構造を使用する場合、以下のようにする必要があります。
+ `base package.business.model` パッケージに記述および追加されます。
+ コンテキストで参照します。他の既存のコンテキストクラスを見て、データ構造クラスを参照し必要に応じてコンテキストメソッド (コンストラクタ、クリーンアップ、リセット) を適応させる方法を確認してください。
専用のコンテキストが用意できたので、新しいプログラムでそれを使用しましょう。
![\[新しいプログラムは、新しく作成されたコンテキストを使用します。\]](http://docs.aws.amazon.com/ja_jp/m2/latest/userguide/images/new_program_uses_context.png)
注記:
+ getContext メソッドは、`ProgramContextStore`クラスの getOrCreate メソッドへのデリゲートと Autowired を使用した Spring `BeanFactory` を使用して、示されているとおりに厳密に実装する必要があります。プログラムコンテキストを `ProgramContextStore` に保存するには単一のプログラム識別子が使用されます。この識別子は「プログラムのメイン識別子」と呼ばれます。
+ コンパニオン設定クラスとコンテキストクラスは `@Import` Spring アノテーションを使用して参照する必要があります。
### ビジネスロジックの実装
プログラムスケルトンが完成したら、新しいユーティリティプログラムのビジネスロジックを実装します。
これをプログラムの `run` メソッドで行います。このメソッドは、別のプログラムまたはスクリプトによってプログラムが呼び出されるたびに実行されます。
コーディングおめでとう\$1
### プログラム登録の処理
最後に、新しいプログラムが正しく `ProgramRegistry` に登録されていることを確認します。既に他のプログラムが含まれるパッケージに新しいプログラムを追加した場合は、何もする必要はありません。新しいプログラムは、アプリケーションのスタートアップ時にすべての隣接プログラムに取り込まれ、登録されます。
プログラム用に別の場所を選択した場合は、Tomcat のスタートアップ時にそのプログラムが正しく登録されていることを確認する必要があります。そのためのヒントを得るには、サービスプロジェクトで生成された SpringbootLauncher クラスの initialize メソッドをご覧ください (「[サービスプロジェクトの内容](#ba-shared-structure-org-service)」を参照)。
Tomcat のスタートアップログを確認してください。すべてのプログラム登録が記録されます。プログラムが正常に登録されていると、一致するログエントリが見つかります。
プログラムが正しく登録されたことを確認したら、ビジネスロジックのコーディングの繰り返しを始めることができます。
## 完全修飾名マッピング
このセクションでは、モダナイズされたアプリケーションで使用するメインフレームおよびサードパーティーの完全修飾名マッピングの AWS 変換のリストを示します。
### AWS メインフレーム完全修飾名マッピングの変換
| 短縮名 | 完全修飾名 |
| --- | --- |
| `CallBuilder` | `com.netfective.bluage.gapwalk.runtime.statements.CallBuilder` |
| `Configuration` | `com.netfective.bluage.gapwalk.datasimplifier.configuration.Configuration` |
| `ConfigurationBuilder` | `com.netfective.bluage.gapwalk.datasimplifier.configuration.ConfigurationBuilder` |
| `ExecutionController` | `com.netfective.bluage.gapwalk.rt.call.ExecutionController` |
| `ExecutionControllerImpl` | `com.netfective.bluage.gapwalk.rt.call.internal.ExecutionControllerImpl` |
| `File` | `com.netfective.bluage.gapwalk.rt.io.File` |
| `MainProgramRunner` | `com.netfective.bluage.gapwalk.rt.call.MainProgramRunner` |
| `Program` | `com.netfective.bluage.gapwalk.rt.provider.Program` |
| `ProgramContextStore` | `com.netfective.bluage.gapwalk.rt.context.ProgramContextStore` |
| `ProgramRegistry` | `com.netfective.bluage.gapwalk.rt.provider.ProgramRegistry` |
| `Record` | `com.netfective.bluage.gapwalk.datasimplifier.data.Record` |
| `RecordEntity` | `com.netfective.bluage.gapwalk.datasimplifier.entity.RecordEntity` |
| `RuntimeContext` | `com.netfective.bluage.gapwalk.rt.context.RuntimeContext` |
| `SimpleStateMachineController` | `com.netfective.bluage.gapwalk.rt.statemachine.SimpleStateMachineController` |
| `StateMachineController` | `com.netfective.bluage.gapwalk.rt.statemachine.StateMachineController` |
| `StateMachineRunner` | `com.netfective.bluage.gapwalk.rt.statemachine.StateMachineRunner` |
### サードパーティーの完全修飾名マッピング
| 短縮名 | 完全修飾名 |
| --- | --- |
| `@Autowired` | `org.springframework.beans.factory.annotation.Autowired` |
| `@Bean` | `org.springframework.context.annotation.Bean` |
| `BeanFactory` | `org.springframework.beans.factory.BeanFactory` |
| `@Component` | `org.springframework.stereotype.Component` |
| `ConfigurableApplicationContext` | `org.springframework.context.ConfigurableApplicationContext` |
| `@Import` | `org.springframework.context.annotation.Import` |
| `@Lazy` | `org.springframework.context.annotation.Lazy` |