COBOLコンソーシアム利用技術分科会
清水 真 (東京システムハウス株式会社 ビジネスイノベーション事業部)
オープン環境に移行した“新システム”の実装に着手する。メインフレームと、UNIXやWindowsなどのオープン環境ではそのベース機能が異なります。実装工程では、このプラットフォーム間の非互換性を理解し、適切に乗り越えていく必要があります。
移行時に解決すべき主な非互換性は、コンパイラ、データの格納方式、画面/帳票の3つであり,ここではコンパイラを解説していきます。
コンパイラを変更すれば、コンパイル・エラーが多発する、コンパイルできてもアプリケーションの動きが変わる、などの不具合が発生します。
これは、各COBOLベンダーが規格に基づきながら固有の拡張機能や、コンパイラ独自の文法である“方言”をコンパイラに実装しているためです。しかし、移行に当たっては、拡張仕様や方言が逆に障害になってしまいます。
これらを修正するためには、まず移行プログラムがどの程度規格以外の文などを使っているかを調べることから始めます。もし規格外の機能を利用している場合は、①移行先のコンパイラでその機能を利用できるか、②規格内の機能で修正できるか、③Cなどの他言語で代替できるか、などの方策を練ります。
以下、コンパイラで発生する非互換とその対策を解説していきます。
COBOLにおいて算術式は、事務処理向け言語として、多くの場面で使われる中核の機能である。その算術式の中間結果の精度において、非互換が存在します。
ひとつ例を挙げましょう。以下のプログラムでは、十の位と一の位を切り落とすことを目的としたものです。
01 A PIC 9（3）. 01 X PIC 9（5）. COMPUTE X = A / 100 * 100
例えば、Aの値が「648」の時、Xの値は「600」となることを期待しています。あるホスト系COBOLのコンパイラでは、中間結果のけた数を、端的に言うと「演算の結果,とりうる整数部/小数部の最大のけた数に合わせる」と規定しています。例の「COMPUTE X = A / 100 * 100」において、中間結果Tの精度は整数部6けた、小数部0けたとなります。よって、
T = A / 100 → Tは6 X = T * 100 → Xは600
となり、このコンパイラでは期待通りに結果が600となります。
ところがこの結果が、（数学的には正しい）「648」になるコンパイラが存在します。この結果を返すコンパイラは、中間結果により高い精度を許容しているためです。比較すると、
T = A / 100 → Tは6.48 X = 6.48 * 100 → Xは648
となります。
中間結果の精度は、各ベンダーそれぞれが定めてよいと規定されているため、このような相違が発生してしまいます。早期にこの問題パターンを見つけて共通的な対応方法を決定しておくことが重要です。
そのほか、以下のような注意すべき非互換があります。
コンパイラごとに予約語の集合に差があります。対策としては、コンパイル・オプションで予約語を制御できるコンパイラを使う方法もありますが、一般的には衝突している予約語を別の項目名に変更します。
日本語定数や16進定数などの記述法に違いがあります。基本的には、移行先の定数記述に書き方を変更することになります。
項目の初期値はVALUE句で規定し,VALUE句のない項目の初期値は未定義です。しかし、コンパイラによっては、英数字項目に空白、数字項目にゼロを初期値で設定します。
VALUE句やINITIALIZE文で初期値を設定するように修正することもできますが、移行先のCOBOLが提供する互換オプションの利用で移行作業を効率化できることも覚えておきましょう。
DISPLAY命令のUPON句で指定される装置名は、特殊名段落の呼び名で定義されハードウエアに依存します。ホスト系COBOLで「UPON CONSOLE」と指定してメッセージをセンター・コンソールに表示していた場合、オープン系COBOLでは異なる動作となることがあります。プログラムの意図する動きとなるように、装置名を変更したりUPON指定の構文を変更する必要があります。
プログラムでのファイルのI/O文の後に、FILE STATUS句で指定された項目に設定される入出力状態値（「35」ファイルなし、「23」二重キーなど）は互換性があります。
しかし、入出力状態値「9X」はインプリメンタ規定の要素であり、コンパイラごとで固有の値を返します。基本的には互換の範囲でのプログラミングがお勧めです。コンパイラごとに固有のものは移行元と移行先での入出力状態値を確認してプログラムを修正する必要があります。
数字項目に数字以外が転送されたり、ファイルのOPEN時にファイルが見つからないときなどのエラー処理について、移行元と移行先のコンパイラで動作が異なることがあります。USE ERROR手続きの宣言についても構文上、差があります。基本的には、移行先の言語仕様と標準エラー後処理に依存せざるを得ません。
COBOLの扱う数字項目には、外部10進数（ゾーン）形式、内部10進数（パック）形式、バイナリ（2進）形式があります。これらは、データ定義時のUSAGE句で定義するが、その定義方法が各コンパイラによって異なります。
また2進形式についても注意が必要です。これらは、コンパイル・オプションで解決できる場合もあるが、基本的には移行元と同じ項目定義、同じ記憶領域となるように、移行先のCOBOLの仕様に合わせて、PICTURE句/USAGE句を修正します。
外部10進数形式は、10進数の1けたが1バイトを占める10進数数の並びとして表現します。特に最右端の1バイトは数字と符号を重ね合わせて表現します。しかしこの符号けたの表現に非互換が存在します。また、内部10進数形式でも非互換はあります。
この対策として、ホスト・コンピュータからオープンシステムにデータを移行する際に符号を移行先に合わせて変換しましょう。
コンパイルの非互換を調査するためには、コンパイラが準拠する範囲を知っておくことが重要です。規格ではCOBOL仕様の範囲を、必須機能と選択機能に区分し、さらにそれぞれの水準（下位/中位/上位）を割り当てています。移行に当たっては、特にインプリメンタが任意に実装する「選択機能」について差があるため注意しましょう。
選択機能の中で注目したいのは、デバッグ機能、通信機能、報告機能の3つです。
デバッグ機能は、COBOL85規格では「廃機能」とされています。最近のCOBOL開発環境には、それぞれに優れたGUIベースのワークベンチやデバッガが用意されており、ここでは特にプログラム修正の必要は無いでしょう。
通信機能とは、DC（Data Communication）とも呼ばれ、システム間のデータのやり取りを規定する機能です。オープンシステムへの移行に際しては、移行先で用意されているTPモニターなどその代替手段との連携の仕組みに変更する必要があります。
報告書作成機能については、オープンシステムの帳票ツールとの連携を検討する必要があり、プログラム修正するか報告書機能をサポートするコンパイラを探す必要があります。
プラットフォームの移行に伴い、文字コードの変換が必要となります。ホスト・コンピュータの文字コードはEBCDICが標準です。ただし、日本語の表示にはベンダー特有の日本語コード（漢字コード）が使用されています。一方、オープンシステムではWindows環境であればSJIS、UNIX環境であればEUCの使用が一般的です。文字コードの変換はプログラミングにも影響します。
これに対処する方法としては通常はプログラムを意図した判定になるように修正することです。
ホスト・コンピュータで稼働している言語はCOBOLだけとは限りません。アセンブラやPL/Iなどの開発言語、簡易言語といったベンダー依存の機能を移行する場合は、COBOL言語での作り直しが近道でしょう。
プラットフォームがオープン環境に変わることにより、アプリケーションや開発環境の作り方に工夫を要することもあります。3つほど紹介しましょう。
アプリケーションのメニュー画面については通常、COBOLや他の言語で独自に作成したものを使用します。また,そのメニューを起動する前にはホスト・システムと同様にアプリケーションに対するアクセス権の管理のため,ログイン画面を表示してユーザーIDやアカウントを入力させます。
オープンシステムではバイナリ・エディタ、リレーショナル型DBに対応したツールなど、様々なツールを組み合わせてデータを編集します。また,編集にはそれぞれのベンダー提供のツールを利用できます。
ホスト・コンピュータでは、COBOLソースコードやJCL、ファイルなどに対するユーザーのアクセス権の管理をはじめ、リソース管理機能はすべてOSが提供しています。オープンシステムではOSが提供するファイル管理やユーザー管理機能で代替するとなると,管理はかなり煩雑になります。そのため、大規模システム開発などでは、オープンシステムの環境に合わせた、事前の開発ポリシーや運用ルール策定が欠かせません。