こんにちは！IBMメインフレームの世界へようこそ。
JavaやCOBOLなどのモダン、あるいは少し前までのビジネス言語をご経験された方にとって、PL/I（Programming Language One）という名前は、どこかレガシーで近寄りがたい雰囲気をまとっているかもしれませんね。
黒い画面、難解な制御ブロック、そして独特のデータ定義……。「間違えたらメモリを破壊してしまうのではないか」と、最初のうちは身構えてしまうのも無理はありません。でも、安心してください。一つひとつの仕様を紐解いていけば、PL/Iは非常に論理的で、プログラマの意図に忠実に動いてくれる頼もしい相棒です。
今回は、そんなPL/Iのデータ制御における「ちょっと奇妙で面白い特徴」と、バッチ処理やデータ移行（マイグレーション）の現場で避けて通れないPICTURE属性の仮想小数点「V」について、メモリの内部構造をのぞき見しながら優しく解説していきますね。
—
1. そもそもPL/Iには「予約語」がない？（ちょっとした脱線話）
本題に入る前に、PL/Iのユニークな性質を一つご紹介させてください。
JavaやCOBOLには、変数名として使ってはいけない「予約語（`if`、`class`、`MOVE`など）」がたくさんありますよね。でも、PL/Iには原則として予約語が存在しません。
例えば、PL/Iではこんなコードが書けてしまいます。
DECLARE IF FIXED BINARY;
DECLARE THEN FLOAT;
IF = 10;
「えっ、`IF`って条件分岐のキーワードじゃないの？」と思われるかもしれませんが、PL/Iのコンパイラは前後の文脈（コンテキスト）から、「おっ、ここにある `IF` は変数だな」「こっちの `IF` は制御文だな」と賢く判断してくれます。
初心者泣かせの仕様ではありますが、「プログラマの自由度を極限まで高めよう」という当時の設計思想の現れだと思うと、なんだか愛らしく感じませんか？
—
2. 本題：PICTURE属性と「仮想小数点（V）」の正体
さて、ここからが本題です。
金融系や基幹システムのメインフレームでプログラムを書いていると、金額や利率を扱うために、以下のようなデータ定義（PICTURE属性）によく出会います。
DECLARE WK-AMOUNT PICTURE ’99V99′ DECIMAL;
Javaの `BigDecimal` や、COBOLの `PIC 99V99 COMP-3` をご存知の方ならピンと来るかもしれませんが、この `V` こが「仮想小数点（Virtual Decimal Point）」です。
「仮想」ってどういうこと？
この `V`、実はメモリ上のどこを探しても実体が存在しません。
「えっ、小数点がないのに、どうやって小数点を表現するの？」って思いますよね。
ここに、レガシーシステムのデータ保持における「容量を1バイトたりとも無駄にしないぞ！」という執念が隠されています。
現実世界（画面や帳票）では、「12.34」のようにドット（`.`）が見えますが、コンピュータの内部（メモリやディスク）でドットそのものを表現しようとすると、文字コードとして1バイト（8ビット）を消費してしまいます。
メインフレームが全盛期だった時代、メモリやストレージは今とは比べ物にならないほど高価でした。「たかがドット1つのために1バイト使うなんてもったいない！」ということで先人たちが編み出したのが、「位置だけ心の中で決めておこうぜ」という仮想の仕組みなんです。
—
3. 内部保持形式（COMP-3 / パック10進数）の世界
PL/Iで `PICTURE ’99V99’` と定義し、さらに内部で効率よく計算・保持するために `DECIMAL`（十進数）を指定すると、データはパック10進数（Packed Decimal / IBM用語では COMP-3）という形式でメモリに格納されます。
ここで、実際に `12.34` という数値がメモリ上でどうなっているのか、解剖してみましょう。
パック10進数の基本ルール
1. 1バイト（8ビット）の中に、数字が2つ（上下4ビットずつ、ニブルと呼びます）詰め込まれます。
2. 最後の1ニブル（右端の4ビット）には、符号（プラスなら `C` や `F`、マイナスなら `D` など）が入ります。
では、変数に `1234`（仮想小数点を考慮して実質 `12.34`）を代入したときのメモリイメージを見てみます。
[ 0001 0010 ] [ 0011 0100 ] [ 1100 ]
( ‘1’ ) ( ‘2’ ) ( ‘3’ ) ( ‘4’ ) ( 符号: ‘+’ )
— 1バイト — — 1バイト — — 0.5バイト —
※実際のバイト境界に合わせるため、全体で合計3バイト（6ニブル）が割り当てられます（最後の半端な部分はパディングされます）。
注目してほしいのは、どこにも「小数点（.）」を表すビット列がないという点です。
メモリ上にはただ純粋に `1234+` という数字の列が並んでいるだけです。
コンパイラはどうやって小数の位置を認識しているのか？
「小数点がないなら、プログラムはどこに小数点があるのか忘れてしまわない？」と不安になりますよね。
そこはご安心を。PL/Iのコンパイラは、ソースコードの `PICTURE ’99V99’` という宣言を読み込んだ時点で、「この変数の下から2桁目が小数点の位置だ」というメタ情報（設計図）をしっかり記憶しています。
そのため、以下のような演算を行ったとき：
DECLARE A PICTURE ’99V99′ DECIMAL INIT(12.34);
DECLARE B PICTURE ’99V99′ DECIMAL INIT(01.11);
DECLARE C PICTURE ’99V99′ DECIMAL INIT(0);
C = A + B; / 足し算をする /
コンパイラは、メモリ上の実体である `1234` と `0111` をそのまま整数として足し算（`1234 + 111 = 1345`）しつつ、頭の中（設計図）で「小数点は下から2桁目だから……結果は `13.45` だな」と計算の帳尻を合わせてくれるのです。人間側がわざわざ `100` を掛けたり割ったりするシフト演算を書く必要はありません。コンパイラが裏で完璧にやってくれます。
—
4. 実務で役立つ！PL/Iコード例と注意点
それでは、実際に仮想小数点 `V` を使った簡単なPL/Iのサンプルプログラムを見てみましょう。マイグレーションやバッチ改修の際によくあるパターンを模しています。
/ —————————————————- /
/ プログラム名: CALCVAMT /
/ 概要: 仮想小数点を持つ単価と数量から金額を計算する例 /
/ —————————————————- /
CALCVAMT: PROC OPTIONS(MAIN);
/ 変数の宣言 /
/ 5桁のうち下2桁が小数（例: 123.45） /
DECLARE WK-UNIT-PRICE PICTURE ‘999V99’ DECIMAL;
/ 数量は整数3桁 /
DECLARE WK-QTY PICTURE ‘999’ DECIMAL;
/ 金額は7桁のうち下2桁が小数（例: 12345.67） /
DECLARE WK-TOTAL-AMT PICTURE ‘99999V99’ DECIMAL;
/ 1. データの初期化（代入時は普通にドット付きで書けます） /
WK-UNIT-PRICE = 125.50; / 内部では ‘012550+’ として保持 /
WK-QTY = 10; / 内部では ‘010+’ として保持 /
/ 2. 計算処理 /
/ コンパイラが仮想小数点の位置を自動調整して計算します /
WK-TOTAL-AMT = WK-UNIT-PRICE WK-QTY;
/ 3. 結果の確認（DISPLAYでコンソールに出力） /
DISPLAY(‘単価: ‘ || WK-UNIT-PRICE);
DISPLAY(‘数量: ‘ || WK-QTY);
DISPLAY(‘金額: ‘ || WK-TOTAL-AMT);
END CALCVAMT;
初学者がハマりやすい注意点
ここで一つ、実務でよくあるハマりどころをシェアしておきますね。
JavaやC言語などの感覚で、異なる小数点位置のデータを直接代入したり、外部ファイル（COBOLのファイルなど）とデータレイアウトを突き合わせたりするときに、仮想位置（Vの数）がずれていると思わぬ桁あふれや計算ミスが発生します。
- データ移動（MOVE / 代入）時:
PL/Iは賢いので、異なる `PICTURE` 型同士を代入しても、コンパイラが自動的に小数点の位置を揃えて（アラインメントを調整して）値を代入してくれます。
- バイナリ直読み（UNSPEC関数など）時:
もしファイルから生のバイト列をそのままメモリに読み込み、仮想小数の存在を無視して直接バイナリ操作しようとすると、値が何百倍にも化けてしまいます。「データが狂った！」とパニックになる原因の大半はこれです。メモリ上のバイナリには「V」の文字はない――この原則を忘れないようにしましょう。
—
おわりに
いかがでしたでしょうか？
PL/Iの `PICTURE` 属性における仮想小数点 `V` は、一見すると古臭く、呪文のような複雑な仕様に見えるかもしれません。しかしその実態は、限られたハードウェア資源を極限まで効率的に使い、かつビジネス計算で最も厄介な「小数点のズレ」をコンパイラに安全に管理させるための、先人たちの美しく洗練された知恵の結晶です。
「メモリのどこにもドットが存在しない」という事実を知っていれば、もうレガシーな定義を見ても怖くありませんよね。
メインフレームの世界は、最初はルールが独特で戸惑うことも多いですが、仕組みが分かってくると非常にカチッとしていて、ロジカルで面白い世界です。日々の開発やマイグレーション作業のなかで、「これってどういうことだろう？」と疑問に思ったときは、ぜひまたこのブログを覗きに来てくださいね。あなたのレガシーライフを、心から応援しています！
