Tech

COBOLからCOBOLへの移行時のポイント!方言と帳票が肝

COBOLで作成したシステムのリプレースは他社COBOLへの移行でも難しい面があります。

RDBを変更する場合と似ていますね。(例えばOracleからPostgreSQLへ変更のケース)

A社製COBOLから、B社製COBOLへの移行の場合でもベースの機能が異なるために乗り越えていく壁がいくつかあります。
当然、変更先のCOBOLコンパイラがオプションなどで動作を切り替えるなどサポート範囲が広い側へ行く場合はいいのですが、サポート範囲が狭い側への移行はいろいろ苦労します。
無意識でメーカ独自の拡張部分を使っているケースが多々あります。

複数のCOBOLコンパイラを使った経験をもとに紹介します。

同じCOBOLだから移行も簡単と思うと痛い目に遭います
この部分に関して深堀します。

方言(非互換性)

COBOLは各ベンダーがISOなどの規格に準拠しながら、固有の拡張機能や独自構文を取り入れています。
この独自部分を方言という言い方をします。

大別するとコンパイル時にコンパイルエラーになるものと実行時の結果が異なるものがあります。

一例

・省略時の初期値の違い
・計算結果が異なる
・ファイルステータスが異なる
・予約語が異なる

省略時の初期値の違い

データ項目の初期値はVALUE句で設定し,VALUE句のない項目の初期値は未定義です。
しかし、コンパイラによっては、英数字項目に空白、数字項目にゼロを初期値で設定します。

01 A PIC 9(3).
01 D PIC X(4) .

VALUE句やINITIALIZE文で初期値を設定するように修正するか、コンパイラによっては互換オプションで変更することも可能です。
コンパイル時のオプションだったり、実行時のオプションだったりします。
互換オプションがない場合は、プログラムを変更するしか方法はありません。

計算結果が異なる

中間結果の精度が各コンパイラの作成ベンダーが定めてよいと規定されているために計算結果が異なる場合があります。

プログラム例
———–
01 DATA1 PIC 9(3).
01 RESULT PIC 9(5).

COMPUTE RESULT = DATA1 / 100 * 100
—–

DATA1 = 734 の場合、計算結果に違いがあります。

(1)中間結果を保持  TEMP = DATA1 / 100
(2)最終結果     RESULT = TEMP * 100

<A社コンパイラ> 数学的には正しい
TEMP = 7.34
RESULT = 734

<B社コンパイラ> コンパイラの実装として誤りではない
TEMP = 7
RESULT = 700

ファイルステータスが異なる

FILE STATUSで指定された項目に設定される値(00=正常終了、35=ファイルが存在しないなど)は互換性があります。
しかし、「9/xxx」はコンパイラごとで固有の値を返します。
この値で判別している場合は変更が必要です。通常「9/XXX」はエラー処理で使うので検査で見つけにくく見落とすケースが多いです。

予約語が異なる

以下のような場合、”RESULT”が予約語のコンパイラではエラーになります。
別名に置換する必要があります。

01 RESULT PIC 9(5).

帳票機能

次の大きな問題は、帳票の印刷機能です。

COBOL 帳票

帳票を印刷するには、専用の帳票作成ツールで帳票の定義ファイルを作成し、COBOLで利用する形になります。
COBOLプログラムで利用するために上記の図にようにCOBOLコンパイラベンダーもしくはサードパーティーの帳票作成ツールを使用しています。

このツールもしくは作成したファイルの互換性がないための帳票の定義ファイルを再作成が必要になります。
COBOLコンパイラの互換性の問題より、大きいな問題になる可能性があります。

まとめ

他社COBOLへの移行の難易度は、移行先のCOBOLのサポート範囲、帳票ツールの選定が肝になります。