すべてのカテゴリ

はじめに メインフレームのオープン化に伴い、アセンブラで書かれていた資産を 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バイト確保され

先月から取り組んでいる古いシステムの改修作業が、予想以上に大変な作業になっています。 10年以上前に作られたシステムで、当時とは技術的な環境がガラッと変わっているんです。 まさに「こんなはずじゃなかった」という状況の連続でした。 改修作業で特に苦労したのは、3つのポイントです。 まず、古いプログラムのコードを読み解くのに時間がかかりました。当時の開発者の方の考え方を理解するのに、まる2日かかってしまいました。 次に、データベースの構造が現在の標準的な作り方と大きく異なっていて、データの移行作業で予想外のトラブルが発生しました。 最後に、新しいセキュリティ基準に合わせるため、ログイン機能を一から作り直す必要が出てきました。 古いシステムの改修には、実はメリットもたくさんあります。 既存のデータをそのまま活用できるので、お客様にとってはコストを抑えて機能アップできます。 また、長年使い慣れた操作感を残しつつ、新しい機能を追加できるので、スタッフの方の負担も最小限に抑えられます。 そして、システム全体を入れ替えるよりも、はるかに短期間で改善効果を実感していただけます。 古いシステム改修のコツをお伝えすると、まず現状の徹底的な調査が欠かせません。 私は改修前に必ず、既存システムの動作を細かくチェックして、どの部分が重要でどこを変更できるかを整理します。 また、段階的に改修を進めることで、途中でトラブルが起きても影響を最小限に抑えられます。 無理に最新技術にすべて置き換えようとせず、必要な部分だけを現代的にアップデートする方が成功しやすいです。 以前にも、古いシステムを改修を手掛けた後は

山村風太です。「このシステム、もう限界なんです…」スタートアップや中小企業から、よくこんな相談を受けます。何年も前に作られたレガシーシステム。メンテナンスが困難で、新機能を追加するたびにバグが発生。でも、業務は止められない。どうすればいいのか。。。レガシーシステムの刷新は、エンジニアにとって最も難易度の高いミッションのひとつです。でも、正しい手順を踏めば、リスクを最小限に抑えながら移行できます。僕が実践しているのは、「段階的移行アプローチ」です。まず、現行システムの全体像を把握します。どの機能が、どの業務で、どれくらいの頻度で使われているのか。ここを理解しないと、優先順位を間違えます。次に、新システムと並行稼働させる期間を設けます。いきなり切り替えるのではなく、両方を動かしながら徐々に移行。何か問題が起きても、すぐに元に戻せる状態を維持します。そして、ユーザーとの密なコミュニケーション。現場の声を聞きながら、必要な機能を優先的に実装していく。完璧を目指すより、まず使える状態を作ることが大切です。レガシーシステムは、企業の歴史そのもの。それを尊重しながら、新しい未来を作る。技術だけじゃなく、寄り添う姿勢が問われる仕事だと思っています。もし同じ悩みを抱えているなら、一緒に解決策を考えましょう。