はじめに
メインフレーム開発環境をできるだけ標準的な技術を使ってモダナイズしていく際に直面するであろう課題の具体例を取り上げていきます。
ここではプロジェクト固有の利用方法に関連する課題を見ていきます。
関連記事
メインフレーム開発環境モダナイゼーションにおける課題 - 前置き
メインフレーム開発環境モダナイゼーションにおける課題 - 1. オープン系とメインフレームの差異に関する課題
メインフレーム開発環境モダナイゼーションにおける課題 - 2. プロジェクト固有の利用方法に関する課題
メインフレーム開発環境モダナイゼーションにおける課題 - 3. 組織/人材に関する課題
プロジェクト固有の利用方法に関する課題
現在使用しているS/Wやミドルウェアと、新環境で使おうとしている仕組みとの相性によって不都合が生じる場合があります。
また、開発サイクル上でのプロジェクト独自の複雑な運用方法や特殊なツールを使っている場合には、それらを新しい環境にどのように適用させていくのかを個別に検討していく必要があります。
具体的な例をいくつか見ていきます。
(1) 現在使用しているS/W、機能との相性
例えば以下のような機能を使用している場合、利用できる機能が制限されてしまうといったことがあります。
【PL/Iマクロ】
アプリケーション開発言語としてPL/Iを使用していてPL/Iマクロを多用している場合、残念ながらVS CodeのIBM Z Open EditorではPL/Iマクロに対応していないためにエディターでのSyntax Checkがうまく機能しません。エラーを示す赤い下線が大量に表示されてしまうことになります。
上のようにPl1: Disable Problemにチェックすることでエディター上のエラーが無視されるようになります。Syntax Checkの部分は実質無効化となりますが、エディター機能として使う分にはPCOMに比べればリッチな機能が提供されるので、UIとしてはだいぶ改善されると思います。
【SAIL/CAP-A】
SAILやCAP-Aという金融系ソリューションのパッケージ製品を使用している場合、業務プログラム間の呼び出しはSAIL/CAP-Aの制御コードを介して行われることになります。このため、ADDIというソースを分析するためのツールや、IDzのzUnitという単体テスト支援ツールとは相性があまりよくないため、別ツールの利用や個別の考慮が必要になります。
【旧バージョンコンパイラ】
使用しているコンパイラがEnterprise COBOL, Enterprise PL/I 以前の古いコンパイラを使用していると、使用したいツールの機能制限が生じる場合があります(IDz zUnitなど)
このように、現在使用しているS/Wや機能と新しい開発スタイルに置き換えた場合に使用したい機能がマッチするかは個別に精査していく必要があります。一部の機能については制約がある前提で割り切って使用する、といった判断も出てくるかと思います。
(2) ロード・モジュール作成/管理方法
ソースの管理方法だけでなく、それをどのようにビルド(コンパイル/リンク)してロードモジュールを作成/管理しているかというのは、プロジェクトの方針やアプリケーションの特性によってもまちまちだと思われます。後々の監査のためにオブジェクト・モジュールやJOBLOGなども含めエビデンスとして何をどう残すのかといったこともプロジェクトそれぞれの事情があると思います。
新しい開発スタイルの中でこれまでの管理方法をどう実現するか、あるいは、新しいスタイルに合わせて変えていくのかということを検討する必要があります。
例えば、DBB, zAppBuildを利用してロード・モジュールを作成する(コンパイル/リンクする)ことを想定すると、zAppBuildは汎用的に作成されたフレームワークであるため、複雑な管理を行わせたい場合は考慮が必要な場合があります。
ソースと実行モジュールが1:1となるケースは非常にシンプルで分かりやすく、適用が楽だと思います。
【シンプルなロードモジュール作成例】
例えば、一旦ソースからロード・モジュール(単体ロードモジュール)を作成し、それらおバインドして最終的な実行可能モジュールとして作成する、というようなケースもあります。
【複雑なロードモジュール作成例】
zAppBuildとしてはこのような操作は想定されていないので、個別に仕組みは考慮する必要があります。
どのモジュールをどのモジュールにまとめるかといった情報は当然外から与えてあげないといけないですし、それらをどう実装するのかは検討する必要があります(提供されているzAppBuildをカスタマイズするか、新たな仕組みを自作するかなど)。
zAppBuildは汎用的なビルドの仕組みを提供するフレームワークですが、DBBが提供するAPIを使用したGroovyスクリプトをベースに作られています。
ソースはGitHub上に公開されていますのでこちらをカスタマイズして利用することが可能です。
GitHub - zAppBuild
DBBおよびzAppBuildを補足した記事も公開していますので必要であればそちらも合わせてご参照ください。
DBB/zAppBuildについてのメモ
(3) UT, ITaの組み込み方法
一般的な開発サイクルを考えた場合、コードの作成/改修を行った際は合わせてUT(Unit Test)を実施するのが定石です。しかし、テストのやり方は対象のアプリケーションの形態(オンライン/バッチ)、起動方法、使用するミドルウェアなどに依存して変わってきます。特にメインフレームのアプリケーションの場合は完全な新規で作成するプロジェクトはあまり無く、既存のアプリケーションをベースにした改修が多いと思われます。しかもアプリケーション規模も大きいため、"アプリケーション基盤"と呼ばれるような共通機能を作っていたり、SAILのような業界共通で使用されるミドルウェア的な機能をしているケースが多く、その場合業務アプリケーションのモジュールを単体テストする場合はその利用環境の作法に従う必要があります。
単体テストの基本的なイメージは以下の通りです。
一般論としては、テスト対象のモジュールの動作確認を行うのに必要な環境をDriver/Stubとして準備し、各種テストパターンを入力データとして準備し、出力データを期待値とチェックする、というのが基本的な考え方になると思います。
メインフレーム・アプリケーションの場合は、業務プログラムの利用形態が使用するミドルウェアや共通機能に大きく依存します。ポインターで渡されるメモリの一部のエリアが使われていて必要な入力データが明確になっていなかったり、制御用の数100ものフィールドが必要で業務アプリ担当者が全てのフィールドを把握しきれない、ということも多いようです。そのためにこのような基本的な単体テストが行いにくい状況が生じていることもあると思われます。そもそも個々のプログラムの単体テストは行わないというプロジェクトも多いようです。
新しい開発サイクルに変えていく際に、UT, ITaをどのように組み込んでいくかというのは重要な検討課題になります。理想的には、単体テストが行いやすいようにアプリケーション全体のリアーキテクトを行い、テスト用のフレームワークも準備するという方向性が望ましいと考えます。
しかし、規模の大きいメインフレームのアプリケーションを一気にそのような形に変えていくのは時間もコストもかかってしまうため、落としどころとして、まずはITaのテストシナリオを実行することでUTをカバーできるような仕組みにしておき、将来的にはUTを行えるような構造に順次置き換えていくという方針も考えられます。
ITaによる単体テスト代替イメージ
テストをある程度バッチ的に実行できるようにしておくことは、将来的な自動化につなげやすくなるため非常に重要です。例えばJenkins等に代表されるようなCI/CDパイプラインをメインフレームの開発サイクルに組み込んでいくにはテストの自動化というのは非常に重要な要素となります。