こんにちは！IBMメインフレームの世界へようこそ。
JavaやCOBOLといったモダン、あるいは従来型のビジネス言語の経験がおありの方にとって、PL/I（ピーエルアイ）という名前を聞くだけで「なんだか難解そう」「歴史のありすぎるレガシーな代物だ……」と身構えてしまうかもしれませんよね。
でも、どうぞ安心してください。どんなに古い仕組みであっても、本質を一つずつ紐解いていけば「なるほど、理にかなっているな」と腑に落ちる瞬間が必ずやってきます。
今回は、PL/Iの数あるユニークな機能の中でも、金融や流通などの基幹系システムで避けて通れない「PIC ‘V’（仮想小数点）」をテーマに、実例を交えて優しく、深く解説していきますね。
—
1. なぜ「小数点」を物理的に持たせない必要があるの？
Javaで金額を扱うとき、`BigDecimal`を使ったり、小数点をそのまま保持したりしますよね。COBOLでも `PIC 9(5)V92` のように書いて仮想小数点を表現しますが、PL/Iでもこれと非常によく似た考え方をします。
さて、ここで少し考えてみてください。
コンピュータのメモリや磁気ディスク（ファイル）の世界において、「`.（ピリオド）」という文字も、実は1バイトの文字データとしてしっかり容量を食っています。
もし、1億円を扱うために `100000000.00` と物理的な小数点まで保存しようとすると、そのドットのせいで余計なメモリやストレージを消費してしまいますよね。さらに、ハードウェアレベルの2進数演算（固定小数点演算）において、ピリオドという文字が混ざっていると計算が非常に面倒になります。
そこで登場するのが、「メモリ上には数字だけを詰め込み、データの何番目と何番目の間に『見えない小数点（仮想小数点）』があることにしよう」という、先人たちの知恵なのです。
これが、PL/Iにおける `PIC ‘V’` の正体です。
—
2. JavaやCOBOL経験者が驚く、PL/Iの「PIC ‘V’」の正体
COBOLを触ったことがある方なら、「あぁ、仮想小数点ね、知ってるよ」と思われるかもしれません。しかし、PL/Iのピクチャー句（データ属性）は、より柔軟で、かつ厳密なルールを持っています。
言葉だけだとイメージしにくいので、実際のコードを見てみましょう。
以下のPL/Iコード片をご覧ください。
DCL 1 WK-DATA,
/ 整数部3桁、小数部2桁の仮想小数点を持つ金額項目 /
/ 合計5桁の数字としてメモリに格納されます（物理的なドットは存在しません） /
3 WK-KINGAKU PIC ‘999V99’,
/ 演算用のワークエリア /
3 WK-KEISAN PIC ‘9(5)V99’;
ここで使われている `V` こが、Virtual（仮想） の頭文字です。
- `PIC ‘999V99’` の場合：
- メモリ上には、例えば `12345` という数字だけがスッキリと格納されます。
- しかし、PL/Iコンパイラはこの変数を扱うとき、自動的に「これは `123.45` なんだな」と頭の片隅（というかコードの生成結果）で解釈してくれます。
⚠️ 初学者が一番ハマる罠：画面や帳票に出力するとき
ここで一つ、実務でよくある「やっちまった！」というトラブルをご紹介します。
仮想小数点はあくまで「メモリ上の計算や保持の工夫」に過ぎません。そのため、この `WK-KINGAKU` をそのまま画面（3270画面）やログ、あるいはCSVファイルにポンと出力しても、勝手に小数点が表示されるわけではありません。
そのまま出力すると、`123.45` ではなく `12345` と出力されてしまい、「あれっ、金額が100倍に膨れ上がってる！？」というパニックに繋がります。
出力や表示の際には、仮想小数点（`V`）ではなく、実在する小数点（`.`）を持つピクチャー句に一度データMoved（転記）してあげる必要があります。
DCL OUT-KINGAKU PIC ‘ZZZ,ZZ9.99’; / 実際にカンマやドットを伴う表示用項目 /
/ 計算結果を出力用に転記する際、PL/Iが自動で桁位置（仮想小数点の位置）を合わせてくれます /
OUT-KINGAKU = WK-KINGAKU;
PL/Iのすごいところは、この転記（代入）を行うときに、コンパイラが自動的に `V` の位置を基準にして桁合わせ（位置合わせ）を行ってくれる点です。自分でわざわざ「100で割る」といった算術演算を書く必要はありません。コンパイラが裏で完璧にやってくれます。
—
3. 演算時の桁合わせルールを知る
仮想小数点を持つデータ同士で計算を行うとき、PL/Iはどのように振る舞うのでしょうか？
例えば、「単価（整数3桁、小数2桁）」と「数量（整数3桁、小数0桁）」を掛け算するシチュエーションを考えてみます。
DCL TANCA PIC ‘999V99’ INIT(‘12345’); / 実質 123.45 /
DCL SURYO PIC ‘999’ INIT(‘010’); / 実質 10.00 (整数) /
DCL GOKEI PIC ‘9(6)V99’; / 結果受け取り用 /
/ 演算の実行 /
GOKEI = TANCA SURYO;
このとき、PL/Iの内部的な算術ルールでは、オペランドの小数点の位置を自動的に認識し、結果のデータ型に合わせて適切なスケーリング（桁合わせ）を行います。
COBOLなどでは小数点の桁数合わせを意識して一時変数を作ったり、ROUNDED句を細かく気にする必要がありますが、PL/Iは言語仕様として小数点の位置合わせが非常にスマートに組み込まれています。
ただし、注意しなければならないのは「桁あふれ（Overflow）」です。
もし計算結果が受取側の変数の大きさを超えてしまった場合、上位の桁が容赦なく切り捨てられます（コンパイルオプションや条件ブランチでトラップすることも可能ですが）。仮想小数点を使っているからこそ、「小数点より上の整数部が何桁必要になるか」を設計段階でしっかり見積もることが、メインフレームエンジニアとしての腕の見せ所となります。
—
4. まとめ：レガシーの仕様は「怖くない」
ここまで、PL/Iの `PIC ‘V’` による仮想小数点の仕組みについて見てきましたが、いかがでしたでしょうか？
- 物理的なドット（`.`）を持たせず、メモリを節約しつつ正確な小数計算を行うための仕組み
- 「`V`」はVirtualのV。メモリ上はただの連続した数字として存在している
- 演算や代入のときは、コンパイラが勝手に小数点を基準にして桁合わせをしてくれる
- ただし、画面やファイルに出力するときは、実小数点（`.`）を持つ項目に一度移し替える必要がある
レガシーシステムと呼ばれるメインフレームの世界は、限られたハードウェア資源を極限まで効率的に使おうとした先人たちのアイデアの結晶です。その仕組みを一つひとつ紐解いていけば、決して恐れるようなブラックボックスではありません。
日々のバッチ改修や移行調査でPL/Iのコードに出会ったとき、「あ、これはメモリを節約するための優しい工夫なんだな」と、少しでも親しみを感じていただければ幸いです。
それでは、快適なメインフレーム・ライフを！次回の記事もお楽しみに。
