このページの本文へ

舞呉コボ郎のマイグレーション放浪記
第3回 メインフレーム to UNIX 編 / COBOL IFの深掘り
コラム

公開日:2024年9月30日

舞呉コボ郎のマイグレーション放浪記

前回「第2回 メインフレーム to UNIX 編 / COBOL MOVEの深掘り」もぜひご覧ください。

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

マイグレ編 ~メインフレーム to UNIX 繁盛~

郵政民営化が動き出した2000年代中頃から東日本大震災が発生した2010年代はじめ頃のお話です。

前回(第2回 前半)のコラムで紹介した「当社として初めてメインフレームto UNIXのマイグレーションに成功した」ことは、事例発表や口コミを通じて広く知れ渡り、多くの類似案件を受注するに至りました。

仕事量がいっきに増えたので、多くのパートナー会社にも協力してもらい、開発を進めていきました。開発体制を急に拡大させたので、開発要員全体に対してマイグレーション経験者の占める割合が小さく、小火(ボヤ)を発生させてしまうこともしばしば。その都度コボ郎やコボ次郎が案件を飛び回って消火活動を行い、なんとか大事には至らずに済んでいましたが、こうした対応も含め以前より格段に忙しくなっていました。

そんな多忙な時期に、コボ郎の携帯にA社 のプロジェクトマネージャであるX氏から電話がありました。ゴールデンウィークの直前のことです。大火事になっている大規模マイグレーション案件があり、X氏が新たなプロジェクトマネージャに就任して立て直すことになり、力を貸して欲しい、との要請でした。

X氏から詳しく話を聞いたところ、案件は以下のような状況にあることがわかりました。

  • スケジュール的には若干の遅れがある程度
  • 総合テストの直前になって、移行元のメインフレームにおける大量の資産変更を反映させなくてはならない事態となった
  • ツールで資産変換した後、手修正とテストを繰り返す手法を用いてきたため、上記の大量の資産変更を反映させて品質を確保するには時間が全く足りない

コボ郎はこの案件を受けるべきか、ゴールデンウィーク中も悩みに悩みました。そして、やらずに後悔するよりも、火中の栗を拾うことになっても良いと腹を括りました。これまでA社が行ってきたマイグレーションのやり方を捨てて、手修正を伴わない当社のマイグレーション方式に全面的に切り替えることを条件に、X氏の要請を受けることにしたのです。

受諾の知らせを聞いたX氏は喜んだのもほんの束の間、関係者を説得すべくA社内とエンドユーザー企業を奔走し、すぐにリカバリープロジェクトが発足しました。

コボ郎とコボ次郎は、数名の部下と共にエンドユーザー企業に常駐し、A社やエンドユーザー企業のSEたちと共に昼も夜もなく、密接に連携して協働しました。その忙しさは、初めてのメインフレーム to UNIX案件のことを彷彿とさせるほどでした。

リカバリープロジェクトは、次のように進めていきました。

  • 当社の移行方式の説明と合意
  • A社のシステムに当社の変換ツールを適用するために必要な移行方式設計の追加
  • 当社既存ツールへの上記設計の組込み
  • エンドユーザー主体のテスト実施

ツールによる資産変換ができるようなったことで、変換品質は格段に向上。プロジェクトは順調に回復し、当社が参画する前の当初計画に比べて若干の納期遅延程度で完遂しました。若干の軽微なトラブルは発生しましたが、円滑に本番環境へ切替えることができました。

「火中の栗を拾う」とは自分の利益にならないことを言いますが、A社の案件は火中の栗を拾うことにはなりませんでした。本件を契機に、A社から類似案件を継続的に発注してもらえるようになり、「メインフレーム to UNIX」黄金期の要因となりました。とてつもないハードワークでしたが、当社の移行方式に切り替えるという勇気ある英断をしたA社とエンドユーザーの期待に応えるために、時が経つのも忘れて没頭していました。私の思い出に強く残る案件の一つです。また、マイグレーションにおける「手修正の弊害」と「機械的な変換の重要性」を再認識した案件でもありました。

次回は、シーズン1最終回「厳冬期を耐え忍んで次のステップへ」です。

COBOL編 ~「IFの深堀り」~

前回はMOVEの深堀りをしました。今回は、IFを深堀りします。

Rocket® Visual COBOL 9.0 for Eclipse(旧Micro Focus製品)のマニュアル中の「条件式」に記載されている事項のうち、下記赤枠線部「数字作用対象の比較」と「文字作用対象の比較」のところを詳しく見ていきます。ここが一番良く使うところでもあり、間違いを犯しやすいところでもあります。

マニュアルに記載されている条件式の内容

IF命令で、左辺と右辺の属性の組み合わせによって比較のされ方が異なることを理解いただきたいと思います。

プログラマーが意図した比較と、実際に行われる比較が異なる場合にバグが発生します。特に属性が異なる項目間の比較はCOBOL製品の比較仕様を良く理解してコーディングしましょう。

なお、IFの深堀りをテーマにしていますが、単純条件はEVALUATEやSEARCHやPERFORMの条件判定における比較でも同様です。

今回は、MOVEの深堀りで示した属性のバリエーション+αの組み合わせにおいて、IF 左辺 = 右辺の単純条件を判定した場合に、どのように比較されるかを実験して、下記マトリックスに整理しました。

この実験結果は一例としてRocket® Visual COBOLを用いて、コンパイル指令にDIALECT”MF"を指定したものです。DIALECT"MF”は、先進的な機能を多く含んでいるので、メインフレーム系のCOBOLとは異なる部分は多数あります。なお、Rocket® Visual COBOLはコンパイル指令の設定によって、さまざまなメインフレームの動作をエミュレーションすることができますので、コンパイル指令によって下記マトリックスは変わってきます。

下記マトリックスはCOBOL製品やコンパイル指令によって異なりますので、実際に利用される際は皆様がお使いのCOBOL製品のマニュアルを参照してください。

実験結果のマトリックス

上記表はPDF版をダウンロードできます。

凡例

補足説明が必要なものについて、下記に凡例を記載します。※Rocket® Visual COBOL 9.0 for Eclipse のマニュアルで開きますから一部抜粋し、実験結果を踏まえて記述しています。

文字比較 両方の作用対象が同じサイズの場合、上位の文字位置から下位へ向けて、対応する位置の文字が順番に比較される。この比較は、対応する位置で文字の不一致を検出した場合、または作用対象の末尾に達した場合のいずれか早い方で終了する。
両方の作用対象が異なるサイズの場合、短い方の作用対象の右側に、長い方の作用対象と同じサイズになるまで空白を付加したものと見なして比較が行われる。
文字比較(一方が数値) 数字作用対象は、数値データ項目と同じサイズの英数字基本データ項目 (標準データ形式文字) に転記された場合と同様に処理される。その後、この英数字データ項目の内容が文字作用対象と比較される。
(例) 01 ABC PIC X(7) VALUE "123". と 01 XYZ PIC 9(3)V9(4) USAGE COMP-3 VALUE 1.23. を比較した場合
"123△△△△" (ABC) と "0012300"(XYZがX(7)に転記された場合の値) が文字比較されて偽となる。

(例) 01 ABC PIC X(7) VALUE "0012300". と 01 XYZ PIC 9(3)V9(4) USAGE COMP-3 VALUE 1.23. を比較した場合
"0012300" (ABC) と "0012300"(XYZがX(7)に転記された場合の値) が文字比較されて真となる。数値が数字定数の場合、当該数字定数の文字列として文字比較される。数字定数に小数点が含まれる場合は、小数点を削除した文字列として文字比較される。

(例) 01 ABC PIC X(7) VALUE "123". と 文字定数 1.23. を比較した場合(IF ABC = 1.23)
"123△△△△" (ABC) と "123" が文字比較され真となる。
表意文字比較 比較対象の桁数分が全て当該の表意文字である場合に真となる。
(例) 01 ABC PIC X(4) VALUE "0".  01 XYZ PIC X(4) VALUE "0000".
   上記の場合、IF ABC = ZERO は偽、IF XYZ = ZERO は真となる。
比較対象項目が、UTF-8、UTF-16、NCHAR、NCHAR以外DBCSの場合、比較対象の具体的な文字コードを表中に記載する。
UTF-8比較 UTF-8 の比較は、字類 UTF-8 の 2 つの作用対象間の比較である。これらの作用対象のいずれかが字類 UTF-8 でない場合、その作用対象は比較の前に字類 UTF-8 の項目に変換される。
  • 作用対象の長さが等しくない場合、短い方の作用対象がもう一方の作用対象の長さまで (UTF-8 の後続空白文字で) 埋められたものとして比較が実行される。
  • 作用対象の長さが等しい場合 (または追加の埋め込みにより、長さが等しいと仮定された場合)、左端の位置から、対応する位置の文字が順番に比較される。この比較は、一致しない UTF-8 文字が検出された場合、または右端の文字位置に達した場合のいずれか早い方で終了する。対応するすべての UTF-8 文字が等しい場合、作用対象は等しいと見なされる。
  • 最初の一致しない文字が検出された際、比較によって作用対象の関係が判別される。より大きい照合順序値を持つ UTF-8 文字を含む作用対象が、より大きい作用対象となる。
DBCS比較 字類が DBCS であるデータ項目および定数は、比較条件内で任意の比較演算子とともに使用できる。データの変換、編集、または逆編集は行われない。
項類が NCHAR である項目と、項類が NCHAR-EDITED である項目とは区別されない。 である項目と、項類が NCHAR-EDITED である項目とは区別されない。
比較処理では、文字の比較が行われる。DBCS 文字集合の文字同士では、通常は照合順序は付けられないため、DBCS 文字を 2 進数として解釈し、その文字を表すビットパターンの数値に基づいて、文字の照合順序を決定する。
DBCS 文字コード内に SBCS 文字コードが含まれている場合、この照合順序が SBCS と同じ順序で配列されるという保証はない。
ある文字が DBCS および SBCS 文字集合の両方に存在する場合、その DBCS および SBCS 文字は等しいとは見なされない。
PROGRAM COLLATING SEQUENCE 句は、字類が NCHAR または NCHAR 定数であるデータ項目の比較に関しては効果がない。
作用対象同士で長さが異なる場合、長い方と同じ長さになるまで短い方の右側に全角の空白を付け加えたものとして、比較が行われる。
コンパイルエラー
ー判定不可ー コンパイルエラーにはならないが、著者が想定出来る範囲の判定結果とならなかった。(判定する必要性のない組み合わせ)
  • Rocket® Visual COBOL および Enterprise Server は Rocket Software の商標または登録商標です。
  • その他記載されている会社名、商品名等は各社の登録商標または商標です。
  • 免責事項
    • 当コラムに記載した内容に関して、いかなる保証もするものではありません。
    • 記載内容は予告なく変更する可能性があり、記載内容に誤りがあった場合でも一切責任を負いかねます。

関連するソリューション・製品

マイグレーション(モダナイゼーション)
お客さまが作り込まれた貴重なアプリケーション資産を有効活用し、最新のITインフラやミドルウェアを用いたシステムに刷新するソリューションです。
端末エミュレータ
IBM、富士通、日立、NECの各社メインフレーム、およびIBM i(AS/400)のオンライン端末機能(日本語3270、6680、560/20、ETOS、日本語5250)を提供する、端末エミュレータ製品と関連製品についてご紹介します。
EDI-Master B2B for Mainframe
EDI-Master B2B Mainframe(以降、B2B Mainframe)は、各種EDI標準通信プロトコルを含むマルチプロトコルに対応し、対外的なEDIから社内のファイル転送までを一元管理できる、統合データ交換システムです。集配信管理機能、ディスパッチ(自動運用)機能による完全自動運転が可能で、データ交換業務の効率化に貢献します。
「EDI-Master B2B for TLS」と連携することで、「全銀協標準通信プロトコル(TCP/IP手順・広域IP網)」にも対応できます。
  • 本製品は2021年10月1日に「EDI-Master DEX for Mainframe」より「EDI-Master B2B for Mainframe」に製品名称を変更しました。

基幹刷新・マイグレーション 導入のご相談・お問い合わせ

キヤノンITソリューションズ株式会社 (デジタルイノベーション事業部門) ビジネスソリューション統括本部 ビジネスソリューション営業本部