こんにちは、千田です。
業務でCOBOLを扱っていると、
「数字で始まるプログラム名が、Cのシンボルに変換される際に
1 → A, 2 → B, 3 → C … のように置き換えられている」
という現象に遭遇することがあります。
一見するとCOBOL特有の仕様のように見えますが、実際にはこれはCリンケージに起因する挙動です。
本記事では、この現象の正体と背景を整理します。
起きている現象
例えば、次のようなケースです。
- COBOLプログラム名が数字で始まっている
- CALLしているはずのサブルーチンが見つからない
- mapファイルやnm / dumpbinを見ると
プログラム名の先頭が数字 → アルファベットに変換されている
例：
1ABC01 → AABC01
2TEST → BTEST
この変換ルールは環境や処理系に依存しますが、
「数字で始まる名前がそのまま使われていない」点が共通しています。
Cリンケージとは何か
Cリンケージ（C linkage）とは、「C言語と同じルールで、外部シンボルを解釈・結合すること」を指します。
ここで言う「C」とは、C言語そのものではなく、以下のような意味合いです。
- リンカが理解するシンボル名のルール
- 呼び出し規約（Calling Convention）
- データ配置やABI（Application Binary Interface）
多くのOSやミドルウェアは、このCのルールを共通基盤として採用しています。
なぜCリンケージが関係するのか
COBOLは内部的には独自のルールで動作しますが、
- OS機能
- DBアクセスモジュール
- ランタイム
- Cで実装されたミドルウェア
と連携する際には、最終的にCリンケージでリンクされます。
そのためCOBOL処理系は、
「COBOLとしては正しい名前」
「しかしCのシンボルとしては不正な名前」
を、C互換の名前に変換する必要があります。
数字が問題になる理由
Cの識別子（シンボル名）には、基本的に次の制約があります。
- 英字または _ で始まる必要がある
- 数字で始めることはできない
このため、数字で始まるCOBOLプログラム名は、そのままでは使えません。
そこで処理系は、
「先頭の数字をアルファベットなどに置き換えて、Cリンケージ上で有効な名前に変換」
という処理を行います。
これが、
1 → A, 2 → B, 3 → C …
といった変換として観測される正体です。
COBOLだけの仕様なのか？
結論から言うと、COBOLだけの仕様ではありません
これはリンケージの都合によるものです。
実際には、
- 古いFortran
- Ada
- 一部のアセンブラ
- RPC / IDL系ツール
などでも、
「言語上は許される名前を、Cリンケージ用に変換する」
ということは普通に行われています。
ただしCOBOLは、
- 数字始まりのプログラム名が多い
- 外部CALLが多い
という特性があるため、COBOL特有の現象のように見えやすいのです。
注意点：この変換に依存してはいけない
重要な点として、この変換ルールは、
- COBOLの言語仕様ではない
- 処理系・OS・バージョン依存
- 将来変わる可能性がある
という性質を持っています。
したがって、「1はAに変換される前提で設計する」というのは非常に危険です。
安全な設計指針
外部CALLや他言語連携を前提とする場合は、
- 最初から英字で始まる名前にする
- 数字は後ろに使う
- C互換の識別子として成立する名前に揃える
例：
OK : A1TEST
NG : 1ATEST
これだけで、リンケージ由来のトラブルの多くを防ぐことができます。
まとめ
- 数字 → アルファベット変換はCリンケージ由来
- COBOL固有の言語仕様ではない
- Cのシンボル制約を満たすための処理系実装
- 変換ルールへの依存は危険
- 最初からC互換名にするのが最も安全
COBOLと他言語・ミドルウェアをつなぐ場面では、
「Cリンケージを意識する」ことが、トラブル回避の第一歩になります。
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
