1. 導入：なぜ名前の長さを意識する必要があるのか
メインフレーム開発の現場において、外部プログラムやデータセットと連携する際、`EXTERNAL` 属性で宣言された名前の管理は極めて重要です。現代の z/OS 環境では名前の長さに余裕がありますが、レガシー資産を扱う際、かつてのリンカ（Binder）の制約（8文字制限）が思わぬ落とし穴となることがあります。名前が一致しないことによる「リンクエラー（未解決シンボル）」や「意図しないデータ参照」を防ぐための知識を解説します。
2. 基礎知識：EXTERNAL 属性とリンカの仕組み
`EXTERNAL` 属性は、複数のプログラムモジュール間で共通して参照するデータやサブルーチンを指し示すために使用されます。コンパイラはソースコード上の名前をそのまま認識しますが、最終的な実行モジュールを作る「リンカ（Binder）」は、メモリ上のアドレスを解決するためにこの名前をシンボルとして処理します。古い環境では、このシンボル名の上限が8文字に制限されていたため、長すぎる名前は切り詰められたり、あるいは別名（エイリアス）で管理されたりする慣習がありました。
3. 実装と解決策：名前の不一致をどう防ぐか
移行や改修を行う際、ソースコード上の宣言と、実際にロードモジュールに埋め込まれている名前が一致しているかを確認する必要があります。もしソースコード上では「ACCOUNT_HISTORY_DATA」と定義していても、既存のロードモジュールが「ACCHIST」という名前で外部公開されている場合、そのままではリンクできません。
解決策として、`AS` 句を用いた明示的な名前の指定や、リンカ制御ステートメント（ALIAS）での対応を検討します。
4. サンプルプログラム：EXTERNAL 名の明示的な制御
以下のコード例では、ソースコード上の識別子と、外部に公開するシンボル名を明示的に切り分ける手法を示します。
/ PL/Iでの宣言例 /
/ ソース内では分かりやすい名前を使い、リンカ上の名前を固定する /
DCL ACCOUNT_HISTORY_DATA_LONG_NAME FIXED BIN(31)
EXTERNAL(‘ACCHIST’);
/
解説:
1. 括弧内の文字列が、実際にリンカが識別する名前（シンボル名）になります。
2. これにより、ソースコードを読みやすく保ちつつ、
古い環境の8文字制限を回避した名前とリンクさせることが可能です。
/
5. 応用・注意点：現場でのトラブル回避
現場で最も陥りやすいのは、「コードを修正して再コンパイルしたが、リンクマップを確認せず実行してABENDする」というケースです。以下のポイントを必ず確認してください。
・マップファイルの確認
リンク時に生成される「ロードマップ（またはリンカリスト）」を確認し、シンボル名が正しく解決されているか確認してください。
・エイリアスの存在
既存のモジュールにエイリアス（別名）が設定されていないか、JCLの `ALIAS` ステートメントやカタログ情報を確認してください。
・保守性への配慮
どうしても8文字制限を守らなければならない環境の場合、ソースコード内のコメント欄に「なぜこの短い名前なのか」という経緯を残すことが、将来の保守担当者への最大の配慮となります。
「動いているから」と放置せず、リンカレベルの名前解決が正しく行われているかを確認する習慣が、レガシー環境の安定稼働を支えます。
コメント