すべてのカテゴリ

はじめに メインフレームのオープン化に伴い、アセンブラで書かれていた資産を COBOL に変換する作業に携わる中で、言語仕様の“当たり前”の違いが想定外の不具合につながる場面を経験した。 今回はその中でも、「配列の添え字」と「変数の部分参照が 1 から始まる」という COBOL の特徴が、アセンブラや C 言語経験者にとってどれほど落とし穴になりやすいかを、実際の疎通確認試験での事例を交えて紹介したい。 COBOL の添え字・部分参照は 1 始まり COBOL 言語では、配列（OCCURS）の添え字や文字列の部分参照の開始位置が1 から数えるという仕様になっている。 これは COBOL を主戦場としてきた人には当然の前提だが、アセンブラや C 言語で開発してきた人間にとっては強い違和感がある。違いは次のようになる。頭では理解していても、無意識に「0 始まり」で考えてしまうのが経験者の性だ。 疎通確認試験で発覚した問題 実際の疎通確認試験において、入力ファイルの項目に「キー開始位置」が存在していた。この値はアセンブラ時代の仕様を踏襲しており、0 が設定されるケースがある設計だった。 COBOL プログラム側でこの値をそのまま部分参照の開始位置として使用したところ、 キー開始位置 = 0 → COBOL では参照範囲外 キー開始位置 ≥ 1 → 一見、正常動作しているように見える 特に厄介なのは、0 以外の値ではエラーにならず、正しく動いているように見える点だ。原因と対策 原因は単純で、 アセンブラ（あるいは C）的な「0 始まり」の発想 COBOL の「1 始まり」の部分参照

はじめに メインフレームのオープン化対応において、アセンブラからCOBOLへの変換作業は避けて通れないテーマです。 単に「文法を置き換える」だけで済めばよいのですが、実際の現場ではそう簡単にはいきません。 今回の変換作業で特に強く感じたのは、アセンブラ特有の「レジスタ思考」から、 COBOLの「変数（レコード）思考」へ切り替えることが最大の難所であるという点でした。 この記事では、構造化データ（レコード配列）のアクセス処理を例に、 ASM→COBOL変換で直面した“思考の転換”についてまとめます。アセンブラにおけるデータアクセスの考え方 アセンブラでは、構造化されたデータであっても最終的にはメモリ上の並びとして扱います。 今回の変換対象では、以下のような実装が多く見られました。 構造体（レコード相当）の配列 構造体サイズは256バイト固定 レジスタに配列先頭アドレスを設定 項目アクセスは「レジスタ + オフセット」 次の要素へは「レジスタに256を加算」 概念的な ASM の例を示すと、次のようになります。* ASM（概念例） LA R1,AREA ; 先頭アドレス L R2,0(R1) ; 項目A L R3,4(R1) ; 項目B LA R1,256 ; 次のレコードへこのように、アセンブラでは常に「このレジスタはいまどこを指しているのか」「次の要素に行くには何バイト足せばよいか」という、 アドレス演算中心の“機械寄りの思考”が求められます。COBOLにおけるデータアクセスの考え方 一方、COBOLではアドレス計算を意識する必要はほとんどありません。 デ

はじめに メインフレームのオープン化やモダナイゼーションに伴い、アセンブラ資産を COBOL に変換する現場が増えてきました。 ところが、アセンブラから COBOL への変換では、「アセンブラでは当然だった前提が、COBOLでは成り立たない」という問題に直面します。 その代表例が「1バイトの扱い」です。本記事では、アセンブラにおける 1バイト（16進 00～FF）を COBOL ではどう扱うべきか、実体験ベースでまとめます。 アセンブラにおける「1バイト」の世界 アセンブラにおいて 1バイトは、 16進：00 ～ FF 10進：0 ～ 255 という完全な数値範囲として自然に扱えます。 IC / STC：ロード・ストア A / AH / S：数値加減算 CLI：直接比較 ビット単位のマスクも容易 つまり、1バイト＝符号なし整数という前提でロジックが組まれているケースは珍しくありません。 COBOLで1バイト定義が難しい理由 まず直感的に定義しようとすると、次の罠にハマります。 01 WS-BYTE PIC 9. → これは「1桁の数字」であり、0～9 しか表現できません。 01 WS-BYTE PIC X. → これは 1バイトですが文字型であり、数値演算はできません。 つまり DISPLAY（ゾーン）形式では、アセンブラの 1バイト数値（00～FF）を再現できません。 COMP-5 を使えば 1バイトになる？ 次に思いつくのが COMP 系の利用です。 01 WS-BYTE PIC S9(3) COMP-5. 見た目は 0～255 を扱えそうですが、実際には 2バイト確保され

イーロン・マスク氏が率いるDOGEが、アメリカの社会保障局（SSA）の膨大なCOBOLコードを短期間でJavaに移行させようとしているというニュースが報じられました。 この計画に対して、専門家からは多くの懸念の声が上がっています。 SSAのシステムは、社会保障番号の発行や給付金の管理といった核心機能を担っています。 そのため、このシステムの移行が短期間で完了するというのは、実際には非常にリスクが高いとされています。 特に、COBOLは古い言語であり、70年以上前から使用されているため、今の若いエンジニアには馴染みがないかもしれません。 マスク氏の計画では、AIを使ってこの移行を行うということですが、急激な変更がシステム全体に悪影響を及ぼす可能性があるとの指摘があります。 技術者の中には、「短期間での移行は不可能」と懸念する声が多く、過去の事例を振り返ると、大規模なシステム移行が予定通りに終わったケースはほとんどありません。 その背景には、膨大な量のデータやシステムの複雑さが関与しており、実際の開発にかかる工数が予想以上にかさむことが常です。 さらに、COBOLのようなレガシーシステムを理解しているエンジニアが少ない今、若手エンジニアがこのシステムを扱うことになると、予期せぬ問題が起こるリスクも高まります。 特に、システムの大規模な移行や改修では、少しのミスが全体の機能に重大な影響を与えることがあります。 プログラマーとしての視点から見ると、このプロジェクトの進行状況には興味深い側面があります。 コード生成AIを利用することで、一見効率的に移行が進むように思えるかもしれませんが、