リライトツール評価のポイント

皆さま、はじめまして。
TIS株式会社で「Xenlon～神龍　モダナイゼーションサービス」のリライトツール開発を担当している奥と申します。

COBOLやPL/Iなどのレガシーな言語で書かれたシステムを、変換ツールにより他のプログラミング言語に変換する「リライト」手法を検討・採用するお客様が増えてきています。
マイグレーションのソリューションを評価するには様々な観点がありますが、本コラムでは中核となるリライトツールを評価する際のポイントについてご説明します。以下の説明では、COBOLからJavaへのリライトを前提とします。

変換ツールの基本機能

まず、変換ツールによってCOBOLの言語要素（データ記述、手続き）をどこまで自動変換できるかを評価します。
COBOLのすべての構文・言語要素の自動変換を100%カバーしているかどうかに目が行きがちですが、「移行対象である現行資産が確実に移行できるかどうか」が重要です。したがって、現行資産でどのような構文が使用されているかを分析・把握し、それらの要素が自動変換できるかどうかを評価することが望ましいです。
言語要素は多岐にわたりますが、ここではいくつかの要素をピックアップして紹介します。

データ記述

COBOLのPICTURE句やUSAGE句等で表現されるデータ項目の属性に注目します。Javaではデータ型が相当します。使用されているデータ記述が自動変換においてサポートされているか、どのような型（クラス）にマッピングされるかを確認します。項目名がそのまま移行されるのか、それともリネームされるのかも確認します。

集団項目

階層的な集団項目定義が、どのように変換されるかを確認します。また、COBOLでは項目を特定するためにOFを使って上位の階層名を指定しますが、一意に項目を特定できる場合はOF句を省略可能です。Java変換後には省略可能なOF句がどのように扱われるかを評価します。例えば、COBOLでは省略されていたOF句をJava変換時に補完できているかどうかを確認します。

表（配列）

COBOLのOCCURS句を使った表は、Javaでは「配列」として扱われるケースが多いです。COBOLでは表の添え字は1から始まりますが、Javaの配列は0から始まります。このような差異が適切に吸収できているかどうかを確認します。

手続き文

MOVE, COMPUTE, READ, WRITE など、各手続き文の変換対応状況を確認します。手続きによっては何種類かの構文が存在する場合や、オプションとして追加指定できる句が存在する場合があります。これらにも留意して自動変換に対応できているかどうかを評価します。
言語仕様の違いから、COBOLからJavaへの変換がしづらい構文もあります。例えば以下のような手続きを多用している場合は、どのように変換されるか留意してチェックしておきましょう。

• PERFORM文
  指定段落を繰り返し呼出すケースや、PERFORM A THRU B のように複数段落をまたがって呼び出すケースがあります。Javaのforループや、メソッド化した上での呼出しなど、意図通りの変換がされるか確認します。
• GO TO文
  Javaの制御構文にはGO TO文に相当するものがないので、他の制御構文を使って実現する必要があります。手作業での移行を強制したり、読み解くのが難しいコードに変換されるものもあるので注意して下さい。
• COPY - REPLACING文
  COPY句の一部に対してREPLACING機能を使って置換した上で挿入する構文です。Javaではコンパイル時に字句置換する機能はないので、現行資産で使用されている場合は変換方法を確認します。

生成されたコードの正確性

次に、変換により生成されたJavaコードが、COBOLでの挙動を正確に再現できているかどうかを評価します。これについては変換ツールだけでなく、Javaコードが実行時に使用するクラスライブラリによって実装される部分でもあります。

内部表現

COBOLではUSAGE句・SIGN句・PICTURE句によりデータ項目の内部表現や正負の符号の扱いが規定されます。現行資産で使用されている内部表現が、Javaではどのように再現されているか評価します。

データ転記規則の扱い

COBOLでは項目間でデータ転記する場合、受け取り側のPICTURE句やUSAGE句によって、適用される転記時の規則が決まります。例えば、桁よせ、空白詰め、ゼロ埋め、小数点位置合わせなどです。内部表現が異なる場合には値の変換が発生することもあります。この規則がJava変換された際にはどのように扱われるかを確認し、適切な挙動かどうかを評価します。

計算精度

COBOLで実現されている算術演算での計算精度が、Java変換後にも維持されているかどうか確認します。現行資産で固定小数点や浮動小数点を扱うことが多い場合は、特に重要な確認ポイントです。

生成されたコードの保守性

3番目のポイントは、生成されたJavaコードが保守しやすいかどうかです。

集団項目の階層関係

集団項目によってグルーピングされた項目や階層定義された項目が、Javaに変換されてもそのままグルーピングされ、階層関係が維持されているかを評価します。ツールによっては、階層関係を維持せず、すべてフラットな項目にマッピングするケースもあるようです。
集団項目の階層関係がそのままクラスの入れ子構造にマッピングされていると、Java上でも項目間の関係を追跡しやすく、保守性が保たれます。

COPY文によるコードの共有化

COBOLではCOPY文によりプログラム間でデータ記述項を共有することができます。Java変換後も、共通のクラスを参照するような構造にマッピングされれば、保守性を維持することが可能です。ただしCOBOLのCOPY句は様々な構造が定義できますので、どのようなケースでも共通のクラスにマッピングできるとは限りません。どのような構造なら共通のクラスへの自動変換が可能か、確認することをお勧めします。

現行資産との対応（トレーサビリティ）

COBOLのプログラムと、変換後のJavaのクラスとが1対1で対応していることが、トレーサビリティを確保する上で望ましいです。
同様に、COBOLのセクションと変換後のJavaの要素（メソッド）も1対1対応していれば、ロジックの追跡がしやすいでしょう。
COBOLの手続き文とJavaのステートメントとの対応がわかりやすいかどうかも、確認しておきます。

COBOL注記（コメント）の扱い

COBOLのコメントがJava変換後にも引き継げるかどうかも気になるところです。ただし、現行資産において、一つの手続き文の途中にコメントが挿入されているような場合は、機械的なコメント移行が難しいケースもあります。また不要なコメントは移行しない方がかえって保守しやすいです。現行資産の状況と、今後の保守に必要なコメントかどうかを吟味します。

生成されたコードの実行時性能

最後に、生成されたJavaコードに、実行時性能を落とさないような工夫が施されているかどうかを評価します。性能に関しても、生成されたコードだけでなく、実行時に利用するクラスライブラリによって性能担保の工夫が実装されているケースもあります。
性能対策にはツールにより様々なアプローチがあります。例えば「Xenlon～神龍　マイグレーションサービス」では、VSAMアクセス時の高速化の工夫や、CALL呼出しで引き渡すデータ項目の転記を抑制する機構など、様々な性能確保のための仕組みが組み込まれています。（詳細は、こちらのコラムでご確認いただけます。）

最後に

リライトツールを評価する際のポイントを大きく4つに分類してご紹介しました。もちろんお客様によって、重要視される評価の観点が異なる場合もあるでしょうし、移行対象のシステムによっても変わってくることと思います。本コラムが、お客様にとって最適な評価観点を検討する際の参考になれば幸いです。

「Xenlon～神龍　モダナイゼーションサービス」製品ラインナップ

「Xenlon～神龍　モダナイゼーションサービス」シリーズはTIS独自のリライト手法によるマイグレーションを中心としたモダナイゼーションサービスで企業のDX推進をご支援します。