はじめに：PL/Iにおける「構造体の文字列化」という諸刃の剣
基幹システムの現場で長年メインフレームと向き合ってきたアーキテクトなら、一度は目にしたことがあるだろう。何十、何百というフィールドが入り交じる巨大な構造体（`DECLARE`文で定義された階層データ）を、一瞬で一つの文字変数に押し込め、電文として送受信したり、シリアライズしてファイルに吐き出したりするコードを。
JavaやC#といったモダン言語の感覚でいえば、これはオブジェクトのJSONシリアライズや、バイト配列への強引なキャストに相当する。しかし、PL/Iの世界では、これを言語機能の根幹である `STRING`組み込み関数 によって、極めてプリミティブかつダイレクトに実現できる。
「変数名を予約語として気にしなくてよい」というPL/Iの自由度の高い命名規則の裏腹で、このメモリ上の連続性を前提とした操作は、コンパイラの内部挙動やアライメント、そしてマイグレーションの現場において、幾多のエンジニアを深夜のダンプ解析へと追い込んできた。
今回は、この `STRING` 関数による構造体から文字列へのキャストに焦点を当て、メインフレームの深淵と、Java/C#等へのオープン系移行（マイグレーション）における致命的な罠について、徹底的に解説しよう。
—
1. コンパイラ内部のからくり：メモリ上の連続性とアドレス変換
まず、PL/Iがメモリ上で構造体をどのように扱っているかを思い出す必要がある。
C言語の構造体と同様に、PL/Iの構造体もデフォルトではハードウェアの境界調整（アライメント）や効率的なメモリアクセスのために、フィールド間に「パディング（パディングバイト・隙間）」が挿入される場合がある。
しかし、`STRING` 関数を適用する際、あるいは `UNSPEC` と組み合わせてバイナリを操作する際、コンパイラ（Enterprise PL/Iなど）は、指定された構造体の範囲を「一つの連続したメモリスライス」として解釈する。
1
DCL 1
