1. 導入：なぜ今、NOMAPが必要なのか
メインフレーム環境でPL/IやCOBOL等の手続き間呼び出しを行う際、システムは通常、引数に対して「記述子（Descriptor）」を自動生成し、データのコピーや形式変換を行います。これは安全性と汎用性を高める反面、極めて高い処理頻度が求められるループ内や、OSの低レベルAPIを直接叩く際には無視できないオーバーヘッドとなります。本稿では、NOMAPオプションを利用してこのオーバーヘッドを排除し、物理メモリ上のデータを直接操作することで、処理性能を極限まで引き出す手法を解説します。
2. 基礎知識：記述子（Descriptor）とポインタ操作
通常、手続き呼び出しを行うと、コンパイラは引数の長さや属性を記述した「記述子」を作成し、呼び出し先に渡します。これは「呼び出し元と呼び出し先のデータ形式が一致しているか」をシステムが保証するための仕組みです。
対して、NOMAP / NOMAPIN / NOMAPOUT を指定すると、この「仲介役」が省略されます。
・NOMAP：引数の記述子を作成せず、物理的なアドレスを直接渡す。
・NOMAPIN：呼び出し時にコピーを抑制する（入力側の最適化）。
・NOMAPOUT：戻り時にコピーを抑制する（出力側の最適化）。
これらは、ハードウェア命令に近いレベルでデータを制御する際に不可欠な知識です。
3. 実装と解決策：クリティカルセクションの最適化
実装の肝は「データの整合性を自前で管理する覚悟」を持つことです。記述子を介さないということは、呼び出し先で引数の長さを誤認しても、システムはエラーを検知できません。そのため、メモリレイアウトを完全に把握している構造体や、OSの定型API呼び出しに限定して適用します。
4. サンプルプログラム：NOMAPを用いた高速呼び出し例
以下は、PL/IにおいてOSの低レベルサービスを呼び出す際、記述子を介さずに直接アドレスを渡すコード例です。
/
- サンプルコード: NOMAPによるオーバーヘッドの排除
- 構造体の物理アドレスを直接OSサービスへ渡す
/
DCL MY_BUFFER CHAR(4096) BASED(P_PTR);
DCL P_PTR POINTER;
/ 呼び出し先の定義: OPTIONS(NOMAP)により記述子生成を抑制 /
DCL OS_SERVICE ENTRY(POINTER) OPTIONS(ASSEMBLER, NOMAP);
/
- 処理の実行
- 通常であれば、ここで記述子作成のコストが発生するが、
- NOMAP指定により、アドレス値のみがレジスタにロードされる
/
CALL OS_SERVICE(P_PTR);
/
- 注: ここではOS_SERVICE側がP_PTRの指すメモリ長を
- 4096バイトであると完全に認識している必要がある。
- 記述子がないため、長さ情報の不一致はメモリ破壊を招く可能性がある。
/
5. 応用・注意点：現場での陥りやすい罠
NOMAPを使用する際、最も注意すべきは「JNIのCriticalアクセス」と同様の制約です。
・整合性の責任は開発者にある： 記述子がないため、呼び出し先でデータの境界を超えて書き込みを行っても、システムは異常終了（ABEND）を即座に検知できない場合があります。
・デバッグの困難さ： このオプションを使用した箇所でメモリ破壊が起きると、デバッガのトレースが追いにくくなります。必ず「NOMAPを使わない標準的な実装」でロジックの正当性を証明してから、最後にパフォーマンスチューニングとしてNOMAPを適用してください。
・移行時の注意： 既存の標準呼び出しをNOMAPへ切り替える際は、呼び出し先が「記述子を受け取る設計」になっていないか、必ずインターフェース定義（マッピング）を再確認してください。記述子なしで記述子を期待する関数を呼ぶと、即座に致命的なエラーとなります。
コメント