こんにちは、皆さん！IBMメインフレームの世界へようこそ。
JavaやCOBOLのコードをバリバリ書いてきた皆さんにとって、PL/I（ピーエルワン）は、もしかしたら少しばかり異世界のように見えるかもしれませんね。「昔の言語でしょ？」なんて思われることもありますが、いえいえ、とんでもない！今もなお、日本の基幹システムをガッチリと支えている現役バリバリの言語なんです。
特に、PL/Iが持つ独特の機能の一つに、今日の主役である「BIT(n)」型があります。Javaの`boolean`やCOBOLの`PIC 9(1)`とは一味も二味も違う、メインフレームならではの低レベルなデータ操作を可能にするこの型、最初は「なんじゃこりゃ？」と思われるかもしれませんが、一度その魅力と奥深さを知ってしまえば、もう手放せなくなりますよ。
「難しそう…」「レガシーって怖い…」なんて思う必要は全くありません！私と一緒に、一つずつ紐解いていきましょう。大丈夫、怖くないですよ！
—
JavaやCOBOLでは見ない「BIT(n)」って何者？
ビット単位でデータを操るPL/Iの力
皆さん、データは最終的に0と1のビットで表現される、というのはご存知ですよね。Javaでは`boolean`型で真偽値を扱ったり、`int`型で32ビットの整数を扱ったりします。COBOLでは`PIC 9(1)`で1桁の数字、`PIC X(1)`で1バイトの文字を扱うのが一般的です。
しかし、PL/Iの「`BIT(n)`」は、その名の通り、N個のビットの並びを直接扱えるデータ型なんです。
例えば、
- `DCL MY_FLAG BIT(1);` と書けば、たった1ビットのフラグ（真偽値）を表現できます。
- `DCL STATUS_BYTE BIT(8);` と書けば、8ビット、つまり1バイト分のデータを表現できます。
- `DCL ACCESS_RIGHTS BIT(4);` と書けば、4つの権利の状態をまとめて表現できます。
どうでしょう？Javaの`BitSet`やC言語のビットフィールドに近い感覚、と想像してもらうと、少しイメージしやすいかもしれませんね。メインフレームでは、メモリを極限まで効率的に使ったり、特定のハードウェアレジスタを直接操作したりする場面で、この`BIT(n)`が非常に重宝されてきました。
「なぜわざわざそんな低レベルなことを？」と思われるかもしれませんが、基幹システムでは「リソースの有効活用」が何よりも重要でした。たった1ビットのフラグのために1バイトやそれ以上のメモリを確保するのは「もったいない」という発想から生まれた、PL/Iならではの強力な機能なんですね。
—
メインフレームの常識！データのアライメントを理解しよう
「アライメント」って何？メモリの駐車場問題
さて、PL/Iの`BIT(n)`を語る上で避けては通れないのが「アライメント（Alignment）」という概念です。JavaやCOBOLでは、ほとんど意識することのない部分かもしれませんが、メインフレームの世界、特にPL/Iにおいては、これを知らないと痛い目に遭うこともあります。
アライメントとは、簡単に言えば「メモリ上にデータを配置する際の規則」のことです。
ちょっと想像してみてください。広大な駐車場に車を停める場面を。
普通は、1台の車が1つの駐車スペースに収まりますよね。もし、車が駐車スペースの線を跨いで停められたり、斜めに停められたりしたらどうでしょう？他の車が停めにくくなったり、駐車場全体が非効率になったりします。
メモリ上のデータもこれと似ています。CPUがデータを効率良く読み書きできるように、データは特定の「境界」に沿って配置されていることが望ましいとされています。この境界が、一般的にはバイト境界、ワード境界（2バイト）、ダブルワード境界（4バイト）、クワッドワード境界（8バイト）などと呼ばれます。
PL/Iでは、`FIXED BINARY`（固定小数点2進数）のような数値データは、デフォルトでCPUがアクセスしやすいように「整列（アライン）」されます。例えば、4バイトの整数なら4バイト境界に、8バイトの整数なら8バイト境界に配置されるのが理想的、とコンパイラは判断します。
ALIGNEDとUNALIGNED：コンパイラの魔法とデータのパディング
PL/Iのデータ型には、「`ALIGNED`」または「`UNALIGNED`」という属性が暗黙的、あるいは明示的に付与されます。
- `ALIGNED`属性: データは、その型の最適な境界に沿って配置されます。例えば、`FIXED BIN(31)`（4バイト整数）なら4バイト境界に。
- `UNALIGNED`属性: データは、ビット単位で隙間なく詰め込まれます。メモリを最大限に節約したい場合に有効です。`BIT(n)`型は、デフォルトで`UNALIGNED`属性を持ちます。
ここで面白い（そして、時に厄介な）のが、構造体（PL/Iでは`DCL 1 …`で定義する階層構造）の中で、これらの属性を持つデータが混在した場合です。
もし、構造体全体が`ALIGNED`属性（これがデフォルトになることが多い）なのに、その中に`UNALIGNED`な`BIT(n)`や`CHAR(n)`などが混ざっていると、コンパイラは賢く、しかし勝手に、データを整列させるために「パディング（Padding）」と呼ばれる無駄なバイト（隙間）を挿入することがあります。
このパディングは、メモリの効率を悪くするように見えますが、実はCPUがデータを高速に読み書きするための工夫なんです。しかし、この挙動を知らないと、「あれ？この構造体のサイズ、思ったより大きいぞ？」とか、「他の言語と連携したら、データの位置がずれてる！」といったトラブルに繋がりかねません。
—
実践！PL/IコードでBIT(n)とアライメントを体験しよう
それでは、実際のPL/Iコードで、`BIT(n)`の操作とアライメントの挙動を見ていきましょう。WordPressでの表示を考慮して、コメントをたくさん入れますね。
/ —————————————————————— /
/ PL/I プログラムの基本構造 /
/ PACKAGEブロックは、関連するPROCEDUREやデータ定義をグループ化します/
/ —————————————————————— /
MY_BIT_ALIGN_SAMPLE: PACKAGE OPTIONS(MAIN); / メインプログラムとして実行 /
/ —————————————————————— /
/ PROCEDUREブロックは、実際の処理コードを記述する場所です /
/ OPTIONS(MAIN)は、このPROCEDUREがプログラムのエントリポイントである/
/ ことを示します。 /
/ —————————————————————— /
MAIN_PROCEDURE: PROCEDURE OPTIONS(MAIN);
/ ————————————————————– /
/ BIT(1)でフラグ操作を行う例 /
/ ‘1’B は1ビットのバイナリリテラルで、真を表します。 /
/ ‘0’B は1ビットのバイナリリテラルで、偽を表します。 /
/ ————————————————————– /
DCL MY_BIT_FLAG BIT(1); / 1ビットのフラグを宣言 /
MY_BIT_FLAG = ‘1’B; / フラグをONにする /
IF MY_BIT_FLAG THEN DO;
PUT SKIP LIST(‘MY_BIT_FLAGはONです。’); / 条件が真の場合に実行 /
END;
MY_BIT_FLAG = ‘0’B; / フラグをOFFにする /
IF MY_BIT_FLAG = ‘0’B THEN DO;
PUT SKIP LIST(‘MY_BIT_FLAGはOFFです。’); / 条件が偽の場合に実行 /
END;
/ ————————————————————– /
/ 構造体とアライメント：メモリ効率の比較 /
/ SIZE組み込み関数を使って、実際にメモリ上で確保されるバイト数を /
/ 確認してみましょう。 /
/ ————————————————————– /
/ ————————————————————- /
/ ALIGNED属性を持つ構造体。 /
/ デフォルトで、データはバイト境界に沿って配置されます。 /
/ コンパイラが自動的にパディング（隙間）を挿入することがあります。/
/ ————————————————————- /
DCL 1 ALIGNED_STRUCT ALIGNED, / ALIGNEDを明示 (通常これがデフォルト) /
2 FIELD_A BIT(1), / 1ビットのフラグ (UNALIGNEDがデフォルト) /
2 FIELD_B FIXED BIN(31), / 4バイトの符号付き整数 (ALIGNEDがデフォルト) /
2 FIELD_C CHAR(1); / 1バイトの文字データ (UNALIGNEDがデフォルト) /
/ ————————————————————- /
/ UNALIGNED属性を持つ構造体。 /
/ データはビット境界に沿って配置され、無駄なパディングは極力 /
/ 挿入されません。メモリ効率は良いですが、CPUのアクセス速度が /
/ 若干低下する可能性があります。 /
/ ————————————————————- /
DCL 1 UNALIGNED_STRUCT UNALIGNED,/ UNALIGNEDを明示 /
2 FIELD_X BIT(1), / 1ビットのフラグ /
2 FIELD_Y FIXED BIN(31), / 4バイトの符号付き整数 /
2 FIELD_Z CHAR(1); / 1バイトの文字データ /
/ 構造体それぞれのサイズを調べてみましょう /
DCL ALIGNED_SIZE FIXED BIN(31); / 4バイト整数でサイズを保持 /
DCL UNALIGNED_SIZE FIXED BIN(31); / 4バイト整数でサイズを保持 /
ALIGNED_SIZE = SIZE(ALIGNED_STRUCT);
UNALIGNED_SIZE = SIZE(UNALIGNED_STRUCT);
PUT SKIP LIST(‘————————————‘);
PUT SKIP LIST(‘ALIGNED_STRUCTのサイズ:’, ALIGNED_SIZE, ‘バイト’);
PUT SKIP LIST(‘UNALIGNED_STRUCTのサイズ:’, UNALIGNED_SIZE, ‘バイト’);
PUT SKIP LIST(‘————————————‘);
/
【解説】
ALIGNED_STRUCTの場合：
FIELD_A BIT(1) は1ビット。
FIELD_B FIXED BIN(31) は4バイト（32ビット）。通常4バイト境界に配置。
FIELD_C CHAR(1) は1バイト。
コンパイラはALIGNED_STRUCT全体をALIGNEDに保とうとします。
1. FIELD_A (1ビット)
2. FIELD_Aの後に31ビットのパディングが挿入され、FIELD_Bが4バイト境界に配置される。
(1ビット + 31ビット = 4バイト)
3. FIELD_B (4バイト)
4. FIELD_C (1バイト)
結果として、4 + 4 + 1 = 9バイト…になりそうですが、
実際にはALIGNEDな構造体は通常、最も大きなアライメント要求を持つ
メンバーの境界（この場合FIELD_Bの4バイト境界）で整列されるため、
最後のFIELD_Cの後にもパディングが挿入され、構造体全体のサイズが
4の倍数になるように調整されることがあります。
(1 + 31) + 32 + (8 + 24) = 4 + 4 + 4 = 12バイトとなる可能性もあります。
多くの場合、ALIGNED_STRUCTのサイズは12バイトになります。
（FIELD_A (1bit) -> 31bitパディング -> FIELD_B (32bit) -> 24bitパディング -> FIELD_C (8bit) -> 24bitパディング）
合計 (1+31)+(32)+(8+24) = 4+4+4 = 12バイト
UNALIGNED_STRUCTの場合：
FIELD_X (1ビット)
FIELD_Y (32ビット)
FIELD_Z (8ビット)
これらはビット単位で隙間なく詰め込まれるため、
1 + 32 + 8 = 41ビット。これをバイトに直すと、
41 / 8 = 5バイトと1ビット。
なので、通常6バイトが確保されます。
（PL/IのBIT(n)は、必要最小限のバイトに詰め込まれますが、
最終的にはバイト単位でメモリが確保されるため、
1ビット余りが出ても次のバイトが使われます。）
この例では、41ビットなので、最低でも6バイト（48ビット）が必要です。
結果、UNALIGNED_STRUCTのサイズは6バイトになります。
/
/ ————————————————————– /
/ ビット列に対する論理演算の例 /
/ & : 論理AND (ビットが両方1なら1) /
/ | : 論理OR (ビットのどちらか、または両方が1なら1) /
/ ^ : 論理XOR (ビットが異なるなら1) /
/ ~ : 論理NOT (ビットを反転) /
/ ————————————————————– /
DCL STATUS_BITS BIT(8); / 8ビットの状態フラグ /
DCL MASK_ACTIVE BIT(8) INIT(‘00000001’B); / アクティブ状態を表すマスク /
DCL MASK_ERROR BIT(8) INIT(‘00000010’B); / エラー状態を表すマスク /
DCL MASK_WARNING BIT(8) INIT(‘00000100’B);/ 警告状態を表すマスク /
STATUS_BITS = ‘00000000’B; / 全ビットをクリア（初期状態） /
PUT SKIP LIST(‘初期状態 STATUS_BITS:’, STATUS_BITS);
/ アクティブフラグをセット (OR演算) /
STATUS_BITS = STATUS_BITS | MASK_ACTIVE;
PUT SKIP LIST(‘アクティブ設定後 STATUS_BITS:’, STATUS_BITS);
/ 警告フラグもセット /
STATUS_BITS = STATUS_BITS | MASK_WARNING;
PUT SKIP LIST(‘警告設定後 STATUS_BITS:’, STATUS_BITS);
/ エラーフラグをセット (同時にアクティブフラグも立っているかチェック) /
IF (STATUS_BITS & MASK_ACTIVE) = MASK_ACTIVE THEN DO;
PUT SKIP LIST(‘アクティブ中にエラーが発生しました。’);
STATUS_BITS = STATUS_BITS | MASK_ERROR;
END;
PUT SKIP LIST(‘エラー設定後 STATUS_BITS:’, STATUS_BITS);
/ 特定のフラグの状態を確認 /
IF (STATUS_BITS & MASK_ERROR) = MASK_ERROR THEN DO;
PUT SKIP LIST(‘エラーフラグがONです。’);
END;
/ 警告フラグをクリア (AND演算とNOT演算の組み合わせ) /
STATUS_BITS = STATUS_BITS & (~MASK_WARNING);
PUT SKIP LIST(‘警告クリア後 STATUS_BITS:’, STATUS_BITS);
/ 全てのフラグをクリア /
STATUS_BITS = ‘00000000’B;
PUT SKIP LIST(‘全クリア後 STATUS_BITS:’, STATUS_BITS);
END MAIN_PROCEDURE;
END MY_BIT_ALIGN_SAMPLE;
上記のコードを実際にコンパイルして実行すると、`ALIGNED_STRUCT`のサイズが`12`バイト、`UNALIGNED_STRUCT`のサイズが`6`バイトと表示されるはずです。（環境やコンパイラオプションによって若干異なる可能性もありますが、基本的な考え方は変わりません。）
この結果が、まさにコンパイラが自動的にパディングを挿入している証拠なんですね！`UNALIGNED`を指定することで、メモリをギリギリまで詰めることができる、ということが見て取れるかと思います。
—
現場で役立つPL/IのBIT(n)活用術と注意点
COBOLとのデータ連携でハマりがちな罠
メインフレームの世界では、PL/IとCOBOLのプログラムが連携することは日常茶飯事です。このとき、`BIT(n)`型は特に注意が必要です。
COBOLには`BIT(n)`に直接対応するデータ型がありません。そのため、PL/Iの`BIT(n)`で定義されたデータをCOBOL側で受け取る場合、COBOLでは`PIC X`（文字データ）として受け取って、その`PIC X`の中身をビット列として解釈する、という工夫が必要になります。
例えば、PL/Iで`DCL MY_FLAGS BIT(8);` と定義された変数を、COBOLで`01 MY-FLAGS PIC X.`として受け取ったとします。
PL/Iで`MY_FLAGS = ‘10000000’B;`と設定すると、COBOL側では`X’80’`という16進数の値として見えます。COBOLで特定のビットをチェックするには、`IF MY-FLAGS BIT ON ‘10000000’B THEN …`のような非標準機能を使うか、`INSPECT`や自前のビット操作ルーチンを組む必要が出てきます。
異なる言語間でのデータ連携は、常に「同じデータをどう解釈するか」という擦り合わせが肝心なんですね。特に低レベルなビット操作では、この「解釈」の違いが致命的なバグに繋がりやすいので、ドキュメント化とテストが非常に重要になります。
メモリ効率と実行速度：トレードオフを理解する
`UNALIGNED`属性はメモリを節約できる点で魅力的ですが、その代償として実行速度が若干低下する可能性があります。CPUは整列されたデータへのアクセスを得意としますが、`UNALIGNED`なデータは、CPUが複数回メモリにアクセスしたり、データを組み直したりする手間がかかる場合があるからです。
現代の高速なCPUでは、この影響は以前ほど顕著ではないかもしれませんが、メインフレームのような大量のデータを高速に処理する環境では、無視できない要素となることもあります。
そのため、`UNALIGNED`を使うかどうかは、メモリ効率と実行速度のどちらを優先するか、というトレードオフを慎重に検討する必要があります。
- メモリが本当に逼迫しているか？
- そのデータがどれくらいの頻度でアクセスされるか？
- 他のシステムとの連携でUNALIGNEDが必須となるか？
これらの点を考慮して、最適なデータ定義を選択することが、システムアーキテクトとしての腕の見せ所になります。
—
まとめ：PL/Iのビット操作は奥深く、そして強力！
今日はPL/Iの`BIT(n)`型と、それに深く関わる「アライメント」についてじっくり解説してきました。
- `BIT(n)`は、ビット単位でデータを扱えるPL/Iならではの強力なデータ型。
- 「アライメント」は、メモリ上のデータ配置規則。メインフレームでは非常に重要。
- `ALIGNED`と`UNALIGNED`属性によって、コンパイラのパディング挿入挙動が変わる。
- `SIZE`関数で、実際のメモリサイズを確認できる。
- `BIT(n)`に対する論理演算は、ビットフラグの操作に非常に便利。
- 他言語との連携や、メモリ効率と実行速度のバランスを考慮することが重要。
最初は戸惑うかもしれませんが、PL/Iが持つこれらの低レベルなデータ操作能力が、いかにメインフレームの基幹システムを効率的に、そして堅牢に支えてきたか、少しでも感じていただけたでしょうか？
レガシーシステムは、一見すると「古くて難しい」と感じるかもしれませんが、その中には長年の知恵と工夫が詰まっています。一つ一つの仕様を丁寧に紐解けば、決して怖いものではありません。むしろ、現代のシステム設計にも通じる、深い洞察が得られるはずです。
これからも、PL/Iの奥深い世界を一緒に探求していきましょう！
