• コラム

前回「第３回 メインフレーム to UNIX 編 / COBOL IFの深掘り」はこちら

こんにちは。舞呉コボ郎です。今回は、当社のメインフレーム to UNIXがブレイクした時のお話です。

2010年代のはじめから中頃のお話です。

黄金期も過ぎ去り、「メインフレーム to UNIX」の案件数は徐々に落ち着いてきました。要員の稼働状況に応じ、全く関係のない仕事を一時的に手伝う「出稼ぎ」を行うこともありました。

同業の他社の方と話をしても、マイグレーション案件は活況の時とそうでないときのギャップが激しいようです。極端な例では、事業自体を止められたり、一旦止めた後に再開したりしている企業もあるようです。大規模案件の要員収束に合わせて、同規模の他案件が開始するような計画を立てられればよいのですが、そんなに都合よくはいきません。お客さまに提案してから受注するまでに１年以上かかる案件も珍しくないですし、すぐに始まると思っていた案件がなくなってしまうこともあります。受注量と要員確保のバランスを取ることが大変難しいのです。閑散期が来ることはある程度仕方がないと思うのですが、閑散期の過ごし方が大切なのです。「出稼ぎ」のような一時しのぎは極力避けて、少し先を見据えて次のステップに備えるのです。種を仕込むのです。

この時の厳冬期には、「メインフレーム to Windows」の基盤ツールや変換ツールをせっせと仕込みました。なぜWindowsなのかというと……

そして、当時はこんなものを仕込みました。

ようやく1件目の「メインフレーム to Windows」が受注でき、順調に開発を進めていました。そんな最中、当案件ユーザーのM&Aが発表され、暗雲が立ち込めました。いやな予感は当たり、マイグレーション対象のシステムを使わないことが決まり、案件自体も消滅したのです。青天の霹靂でした。ガ、ガ、ガ、ガ－ンです。

そんな中、前回のコラムでお話ししたA社案件の関連で、すぐに別の「メインフレーム to Windows」案件が受注できました。いやー、あの時、勇気を出してA社案件をやって良かったなぁ。人と人との繋がりや義理人情は本当に大切ですね。そして、「メインフレーム to Windows」は狙いどおりにヒットしました。

一方、当時まだメジャーではなかった「メインフレーム to Linux」も技術的には「メインフレーム to UNIX」とほぼ同じなので、ツール類に新たな対応は不要で、Linuxがメジャーになるとともに案件が増えてきました。

厳冬期にもマイグレーションに向き合い仕込みをしてきたことが、当社の今のマイグレーションサービスの基礎になっています。

シーズン１は今回が最終回となります。これまで本コラムをお読みいただきありがとうございました。当社の強みは、脈々と30年以上マイグレーション専門組織を維持し、コボ次郎だけでなくコボ三郎、コボ四郎などに、舞呉家の秘伝を伝承できていることです。これから起こるエピソードについて、彼らがコラムのシーズン2を執筆するときが来るかもしれません。

COBOLの神髄は、MOVEとIFです。MOVEとIFについては、詳しく説明させていただきました。それ以外は、難しいところはありません。所詮、制御構造はどのような言語でも大きく変わりませんし、マニュアルを読めば容易に理解できます。シーズン１の最終回では、マイグレ時に気を付けるポイントについて、コボ郎の経験から得たことの一部をお話ししたいと思います。

COMPUTE命令の計算式は、コンピュータの中で、２項ずつに分割して演算されますので、３項以上の演算では中間結果が使用されます。

（例）COMPUTE A-6 = B-2 * (C-4V1 / D-2V2)

上記の演算では、3項の演算となり、下記のように中間結果を使って計算されます。

C-4V1 / D-2V2 → 中間結果１
B-2 * 中間結果１ → A-6

ここで、重要になるのが中間結果の桁数です。COBOL製品の仕様やコンパイル指令によって、中間結果の最大桁数は、30桁だったり、31桁だったり、40桁だったりします。この３種類は、コボ郎がこれまで出会ったことのあるもので、その他にもあるかもしれません。また、中間結果の小数部桁数を決定する仕様もコンパイラやコンパイル指令によって、微妙に異なる場合があります。上記演算の各項目の属性が下記の場合、某COBOL①では中間結果①がS9(6)V(1) となり、某COBOL②では中間結果②がS9(6)V(2)となります。

某COBOL①の演算結果は次のとおり、A-6＝1347となります。
　C-4V1 【1234.5】/ D-2V2【32.00】 → 中間結果①【38.5】
　B-2 【35】 *　中間結果①【38.5】→ A-6【1347】（A-6は小数部がないので、演算結果の1347.5の小数部は切り落とされる）

某COBOL②の演算結果は次のとおり、A-6＝1349となります。
　C-4V1 【1234.5】/ D-2V2【32.00】 → 中間結果②【38.57】
　B-2 【35】 *　中間結果②【38.57】→　A-6【1349】（A-6は小数部がないので、演算結果の1349.95の小数部は切り落とされる）

中間結果の属性が異なると、演算結果が異なる場合があります。恐ろしいですね。当社では、移行元のCOBOLと移行先のCOBOLがコンパイル時に付与する中間結果の桁数差異を把握し、差異が出る可能性のある演算については、プログラム変換で対応しています。

ビッグエンディアンとリトルエンディアンの違いについては、コラムの第二回を参照してください。移行元と移行先のシステムのエンディアンが異なる場合は、注意しなければならない点が結構あります。

外部から連携されるファイルに変更を加えない場合、移行前同様にビッグエンディアンとしてバイナリ項目が移行後システムに格納されます。COBOLプログラムでビッグエンディアンのバイナリ項目として定義しなくてはなりません。

移行前に下記のように定義されていた場合、IN-BIN01は、COMP-5で定義されているので環境依存となります。移行前環境ではビッグエンディアンとなりますが、移行後環境ではリトルエンディアンとなります。IN-BIN02はCOMPで定義されているので環境によらずビッグエンディアンとなります。よって、下記例として定義されているCOBOLプログラムは移行時に下記のように変更する必要があります。

①DBMSの通信時のデータ変換機能によってバイナリ項目がどのように変換されるのかを確認する。（クライアント側のエンディアンに合わせられるか否か）

②移行後のCOBOLやDBMSプリコンパイラのコンパイルオプションなどにより、バイナリ項目の定義を変更する機能の有無を確認する。

③上記①と②の整合性が合うように、コンパイルオプションや各種設定、必要に応じてCOBOLプログラムの変更で対応を行い、DB内のバイナリ項目を正しくアクセスできるようにする。

COBOLの固定小数点演算で使用できる数値項目の桁数は最大18桁(整数部の桁数＋小数部の桁数)です。固定小数点演算では扱えない大きな桁や小さな小数桁を用いて演算する場合に浮動小数点項目（COMP-1またはCOMP-2）を用いる場合や、非整数（小数部を含む値）のべき乗を求める演算や、浮動小数点が返却される三角関数などの組み込み関数を用いた演算が浮動小数点演算となります。浮動小数点演算は誤差を含みます。誤差を許容できない場合は、浮動小数点の規格（IEEE754 or IBM方式)と単精度か倍精度かによって、誤差の発生する条件を把握した上で、誤差が含まれる桁数を切り捨てるなどのコーディングを行う必要があります。

移行前と移行後で浮動小数点の規格が異なる場合は、小数部の末尾の方の誤差を含む桁は演算結果が異なってきます。移行前のアプリケーションプログラムで適切に誤差の対応を行っていても、移行後の規格では、なんらかの追加対応が必要となる場合が多いです。移行前と移行後の浮動小数点の規格が同じであっても、COBOL製品やコンパイルオプションによって微妙な差分が発生する場合もあるため、必ず早めに差分の有無を確認することをお勧めします。

これまで本コラムに掲載したことが、COBOLを使われている方や、COBOLを移行する方の一助になれば幸いです。ありがとうございました！

• お問い合わせフォームはこちら

※Windowsは、米国Microsoft Corporationの、米国、日本およびその他の国における登録商標または商標です。
※記載の会社名、製品名などは、それぞれの会社の商標もしくは登録商標です。
※免責事項
・当コラムに記載した内容に関して、いかなる保証もするものではありません。
・記載内容は予告なく変更する可能性があり、記載内容に誤りがあった場合でも一切責任を負いかねます。