すべてのカテゴリ

はじめにアセンブラは「CPU に近い制御」を前提とした言語であり、COBOL は「業務ロジックの可読性」を重視した言語です。そのため、アセンブラ的に正しい実装をそのまま COBOL に持ち込むと、動作はしても保守性の低いコードになりがちです。本記事では、実際の移行作業で頻出する「ASM 的には正しいが、COBOL では避けるべきコードパターン」を 5 つに整理して紹介します。パターン①：GOTO 依存の制御構造■ ASM 的な書き方BNE LOOP1BE EXIT👉 分岐命令で処理を飛ばすのが基本。■ COBOL に直訳するとIF A NOT = B GO TO LOOP1END-IFIF A = B GO TO EXITEND-IF👉 処理の流れが追いづらく、スパゲッティ化しやすい。■ COBOL 的に望ましい書き方PERFORM UNTIL A = B ...END-PERFORM👉 制御構造を使い、処理の意図を明確にする。パターン②：1 バイトフラグによる状態管理■ ASM 的な書き方・X'00' / X'FF' で状態管理・フラグレジスタや 1 バイト領域で制御■ COBOL に直訳するとIF FLAG = X"FF"👉 フラグの意味が読み取れず、可読性が低い。■ COBOL 的に望ましい書き方IF END-OF-DATA = TRUE👉 意味のある名前＋論理値で、意図が一目で分かる。パターン③：型を信用せず MOVE を連鎖させる■ ASM 的な書き方PACK ...UNPK ...👉 数値⇔文字の変換を頻繁に行う前提。■ COBOL に直訳するとMOVE A

1. はじめにCOBOL を VSCode で動かしてみたいと思い、GnuCOBOL を Windows にインストールして実行環境を整えました。 日本語でまとまった情報が少なく、特に「VSCode で実行するまで」の手順が分かりづらかったため、今回自分が実際に行った手順をまとめています。インストール画面や VSCode の設定画面もキャプチャしていますので、同じように環境を作りたい方の参考になれば幸いです。2. GnuCOBOL のインストール手順（Windows）● ダウンロード● MSI の実行● インストール完了● 動作確認（cobc –version）cobc --versionバージョンが表示されれば OK です。3. VSCode に COBOL 拡張機能を入れる● COBOL (bitlang) をインストールThemes ではなく “COBOL” を選ぶ点に注意。● 補完・シンタックスハイライトの確認4. HELLO_WORLD を書いて実行する● ソースコード● ビルドcobc -x helloworld.cob● 実行./helloworld.exe● 実行結果5. VSCode でワンクリック実行できるようにする（tasks.json）● .vscode フォルダを作成● tasks.json の内容{ "version": "2.0.0", "tasks": [  {   "label": "COBOL Build & Run",   "type": "shell",   "command": "cobc -x helloworld.cob;

はじめに本シリーズでは、メインフレーム環境で稼働していたアセンブラ（ASM）プログラムを COBOL へ移行する過程で直面した課題を中心に紹介してきました。今回は少し視点を変えて、変換作業そのものではないが、実際の現場では確実に必要になった作業について触れます。いわば「番外編」「付録編」のような位置づけです。移行作業は、プログラムを変換して終わりではありません。オープン環境で動かすためのビルド周りの整備も、確実に必要な工程でした。Makefile 作成を依頼された背景アセンブラから COBOL への変換作業が一段落しつつあった頃、次の依頼が届きました。「COBOL をコンパイルするための Makefile を作ってほしい」対象となる COBOL プログラムは複数本。コンパイル方法はほぼ共通ですが、数が多い。正直なところ、「1本や2本なら手で書けるけれど、この数を全部手作業で作るのは厳しい…」というのが最初の感想でした。手作業での Makefile 作成の問題点手で Makefile を作る場合、次のような問題が見えてきます。・ほぼ同じ内容を何度も書く必要がある・プログラム名の書き間違いが起きやすい・修正が入ると、すべての Makefile を直す必要がある・作業者によって書き方が微妙に変わる特に今回は 対象プログラム数が多い ことがネックでした。「とりあえず作る」ことはできますが、後からの修正や再実行に耐えない作業になってしまいます。自動生成という判断そこで考えたのが、Makefile を手で作るのではなく、“作る仕組み”を作るという方法です。・Makefile の雛形（テンプ

メモリ破壊の正体と、インターフェース再構築の舞台裏はじめに本シリーズでは、メインフレームのオープン化に伴うアセンブラ（ASM）から COBOL への移行について、実務で直面した課題とその対応を紹介しています。今回はその中でも、最も危険で、発見が難しい「メモリ破壊問題」と、そこから派生したインターフェース再設計について取り上げます。現行システムでは、DB アクセスに使用する入出力エリア（I/O エリア）が引数で受け渡されていました。しかし、そのサイズはプログラムごとに異なり、レイアウトも統一されていませんでした。この事実は関係者の間で「なんとなく」共有されていたものの、長年問題なく動いていたため、誰も手を付けていませんでした。今回の移行でも当初は、・現行の COBOL 資産は修正したくない・ASM 部分だけを COBOL 化したい・共通サブルーチンで吸収したいという方針でした。しかし、この判断が後に大きな問題へとつながります。想定していた構造COBOL（業務ロジック）  ↓ASM（I/O 制御）  ↓COBOL（DB ハンドラ）  ↓DB今回の移行では、この ASM 部分を COBOL で書き直し、共通サブルーチンとして置き換える計画でした。問題の本質：I/O エリアサイズの不一致DB アクセスに使用される I/O エリアは、呼び出し元の COBOL プログラムごとにサイズが異なっていました。・あるプログラム：200 バイト・別のプログラム：500 バイト・レイアウトも微妙に異なるこれらは仕様書に明記されておらず、暗黙の契約で成り立っている状態でした。ASM ではこの曖昧さが許容

はじめに アセンブラ⇔COBOL変換シリーズの第4回として、今回はビット演算に焦点を当てています。 メインフレームのオープン化対応では、アセンブラで記述されていた処理を COBOL へ変換する場面が少なくありません。 前回までの記事では、変換時に注意すべきポイントを整理してきました。 その中でも、アセンブラでは当然のように使われているビット演算（AND／OR）は、COBOL に置き換える際に「どの方法が妥当か」を検討する必要があります。 今回は、アセンブラ→COBOL 変換の中でもビット論理演算（AND／OR）に焦点を当て、実際に採用した方法と、その判断理由について整理します。今回は COBOL 標準ではないが CBLUBIT を使用して対応した 結論から書くと、今回の変換では CBLUBIT サービスルーチンを使用して対応しました。 CBLUBIT は COBOL の標準仕様ではありませんが、特定の処理系（IBM 系、日立系など）で提供されているビット論理演算用のサービスルーチンです。 CBLUBIT の基本的な使い方 CALL 'CBLUBIT' USING OP1 OP2 'A' RESULT この 1 行だけで、OP1 と OP2 を AND（論理積）で演算し、結果を RESULT に格納する処理内容が読み取れます。 演算コード - 'A' ：AND（論理積） - 'O' ：OR（論理和） - 'X' ：XOR（排他的論理和） アセンブラ経験者であれば、元の命令の意図をほぼそのまま読み替えられる点が大きな利点です。 なぜ CBLUBIT を採用したのか今回の変換では、以

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

はじめに本シリーズでは、メインフレームのオープン化に伴うアセンブラ（ASM）から COBOL への移行について、実務で直面した課題とその対応を紹介しています。今回はその中でも、私が最初に苦労したレジスタ管理（R0～R15）について取り上げます。COBOL ではデータ項目に名前を付けて管理しますが、アセンブラでは CPU 内部のレジスタを使い分けながら処理を進めます。そのため、解析時には「今このレジスタには何が入っているのか」を常に意識しながらソースを追う必要がありました。レジスタの役割と複数使用の難しさメインフレームのアセンブラには、以下の 16 本の汎用レジスタがあります。R0 ～ R15（汎用レジスタ）レジスタは高速な作業領域として、次のような用途で利用されます。・データの格納・アドレスの保持・パラメータの受け渡し・演算結果の保存・ループ制御実際の ASM ソースでは、複数レジスタが同時に使われることが珍しくありません。・R1：入力データのアドレス・R2：出力データのアドレス・R3：処理件数・R4：ワーク領域・R5：テーブル検索用しかし、これらの役割がコメントに書かれているとは限らず、解析時には「R5 は今どのデータを指しているのか」「この命令で R3 は更新されたのか」といった点を逐一確認する必要がありました。レジスタ追跡の実際解析では、単に「R1 を使っている」ではなく、1 ステップ単位でレジスタの内容を追跡しました。その値が、・テーブルの先頭アドレスなのか・データ領域のオフセットなのか・ループカウンタなのかを確認しながら処理を追う必要がありました。さらに、アセンブラで

はじめにメインフレームのアセンブラ資産を COBOL へ移行する際、必ずといっていいほど直面するのが、 レジスタを使ったパラメータ受け渡し の問題です。アセンブラでは、処理対象データのアドレスをレジスタに設定し、そのままサブルーチンを呼び出すという書き方が一般的です。しかし COBOL にはレジスタという概念がなく、同じロジックをそのまま再現することはできません。今回は、アセンブラ的な「レジスタにアドレスを設定して共通サブルーチンを呼び出す処理」を、COBOL でどのように置き換えたかを紹介します。アセンブラでよくあるパターンLA R9,ARG1BAS R14,ARGCHKL R9,ARG2BAS R14,ARGCHK    このコードでは、以下のような処理が行われています。R9 に処理対象データのアドレスを設定共通サブルーチン ARGCHK を呼び出しサブルーチン側は「R9 の内容」を前提に処理つまり、暗黙的な引数渡し（レジスタ依存） になっています。COBOL での課題COBOL には以下の制約があります。レジスタという概念がないCALL / PERFORM では明示的な引数が必要アドレスではなく「データそのもの」を扱うそのため、アセンブラのように「レジスタにアドレスを入れて呼び出す」という方法は使えません。対応方針：中間バッファ方式今回採用したのは、シンプルで移行しやすい方法です。👉 レジスタの代わりに中間バッファを用意する作業用バッファ（例：R9BUFF）を定義呼び出し前に対象データをバッファへ MOVEサブルーチンは R9BUFF を参照して処理COBOL

はじめに メインフレームのオープン化対応において、アセンブラから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を利用することで、一見効率的に移行が進むように思えるかもしれませんが、