【テクニカル・上級編】STREAM I/OにおけるGET/PUT EDITとフォーマット制御 – PL/Iの基本構文とデータ制御実践ガイド

PL/IのSTREAM I/OにおけるGET/PUT EDITとフォーマット制御：極限の信頼性と移行設計の観点から

基幹システムの心臓部、PL/I。そのSTREAM I/OにおけるGET/PUT EDIT、特にフォーマット制御の奥義は、長年 mainframe の現場を戦い抜いてきた者だけが到達できる境地と言えるでしょう。JavaやC#へのレガシー移行という激流の中で、このPL/Iの基本構文に立ち返り、その真髄を理解することは、単なる構文知識に留まらず、システム全体の信頼性を盤石にし、安全かつ確実な移行を実現するための羅針盤となります。

本稿では、PL/Iプログラムの基本構造であるPACKAGE、PROCEDURE、OPTIONS(MAIN)に触れつつ、STREAM I/OのEDIT指定の役割、そしてピクチャ編集文字を用いたデータ整形と改行制御の仕組みを、現場で遭遇するであろう具体的な課題と、それを乗り越えるための深い知見を交えて解説します。ベース変数とポインタによる動的メモリ操作、コンパイラオプションによる最適化、アベンド（ABEND）発生時のダンプ解析、パックデシマルの内部符号反転バグ、さらにはDB2やCICSといったミドルウェアとの連携におけるエッジケース対策まで、基幹システムアーキテクトとして、あるいは移行プロジェクトのリードとして、押さえておくべきポイントを網羅していきます。

PL/Iプログラムの基本構造：PACKAGE、PROCEDURE、OPTIONS(MAIN)

PL/Iプログラムの出発点となるのは、`PACKAGE`、`PROCEDURE`、そして実行可能プログラムであることを示す`OPTIONS(MAIN)`です。これらの構造を理解することは、プログラムのスコープ、可視性、そして実行フローを把握する上で不可欠です。

/ プログラムの開始点 /
MYPROG: PROCEDURE OPTIONS(MAIN);

/ ここにメインロジックが記述されます /

/ 例: 変数宣言 /
DECLARE
INPUT_RECORD CHAR(80) VARYING, / 入力レコード用 /
OUTPUT_LINE CHAR(132) ; / 出力行用 /

/ STREAM I/O の開始 /
ON ENDFILE(SYSIN) BEGIN;
PUT SKIP LIST(‘入力ファイルの終端に達しました。’);
GO TO END_PROGRAM; / プログラム終了へ /
END;

/ ファイル処理ループ /
DO WHILE (1);
GET FILE(SYSIN) EDIT (INPUT_RECORD) (A); / 標準入力からレコードを読み込み /

/ ここでレコードの加工処理などが行われる /
/ 例: 単純なコピー /
OUTPUT_LINE = INPUT_RECORD;

PUT FILE(SYSPRINT) EDIT (OUTPUT_LINE) (A); / 標準出力へ書き込み /
END;

END_PROGRAM:
PUT SKIP LIST(‘プログラムを正常終了します。’);

END MYPROG;

`OPTIONS(MAIN)`を指定された`PROCEDURE`がプログラムのエントリーポイントとなります。`PACKAGE`は、関連する`PROCEDURE`や変数、型などを論理的にまとめるための構造ですが、小規模なプログラムでは省略されることも少なくありません。しかし、大規模なレガシーシステムにおいては、`PACKAGE`が複雑にネストされていたり、異なる`PACKAGE`間での依存関係が絡み合っていたりすることが、移行時の解析を困難にする要因の一つとなります。

`ON ENDFILE(ファイル名)`句は、ファイル終端時のエラーハンドリングを記述します。これは、プログラムが予期せず終了するのを防ぐための重要な機構ですが、このハンドラ内で適切な終了処理（リソース解放、最終的なサマリー出力など）を行わないと、後続の処理に影響が出たり、リソースリークの原因となったりする可能性があります。

STREAM I/OにおけるGET/PUT EDITの真髄：データ整形と改行制御

PL/IのSTREAM I/Oにおける`GET`および`PUT`文は、レコード指向の`READ`や`WRITE`とは異なり、データストリーム全体を連続したバイト列として扱います。このストリームをどのように解釈し、どのように出力するかを制御するのが`EDIT`指定です。

`EDIT`指定は、データ項目と、それをどのようにフォーマットするかを記述したピクチャ編集記述子のペアを記述します。これにより、数値データの桁埋め、小数点位置の調整、文字列の埋め込み、さらには改行の挿入などを細かく制御できます。

ピクチャ編集文字：データ整形のエキスパート

ピクチャ編集文字は、`EDIT`指定の肝となる部分です。代表的なものをいくつか見てみましょう。

`X`: 文字データ（ASCII/EBCDIC）を表します。
`A`: 文字データ（ASCII/EBCDIC）を表します。`X`と似ていますが、NULL文字などを扱える範囲が広い場合があります。
`9`: 数値データ（0-9）を表します。
`V`: 小数点位置を表します。実際のデータには現れず、内部的な位置を示します。
`S`: 数値の符号を表します（`+`、`-`）。
`Z`: 総ゼロ抑制を表します。先頭のゼロを空白に置き換えます。
“: 総ゼロ抑制としてアスタリスクを出力します。小切手などで不正利用を防ぐためによく使われます。
`$`: 通貨記号（ドル記号）を先頭に挿入します。
`B`: 空白文字を挿入します。
`/`: スラッシュを挿入します（日付などで使用）。
`.`: 小数点を挿入します。

これらの文字を組み合わせることで、非常に柔軟なデータフォーマットを実現できます。

コード例：数値と文字列のフォーマット

MYPROG: PROCEDURE OPTIONS(MAIN);

DECLARE
NUM_INT FIXED BINARY(31), / 整数 /
NUM_DEC PIC ‘-9999.99’, / 小数点付き数値 /
STR_DATA CHAR(20), / 文字列 /
PACKED_DEC PIC S9(5)V99; / パック10進数 /

/ サンプルデータの初期化 /
NUM_INT = 12345;
NUM_DEC = 123.45;
STR_DATA = ‘PL/I PROGRAMMING’;
PACKED_DEC = 987.65;

/ 整数を固定幅で出力 (ゼロ埋め) /
PUT SKIP EDIT(‘Integer: ‘, NUM_INT) (A, X(8), F(7));
/ F(n) は固定長フィールドを表し、数値の場合はゼロ埋めされます。 /

/ 小数点付き数値をフォーマットして出力 /
PUT SKIP EDIT(‘Decimal: ‘, NUM_DEC) (A, X(8), PIC(‘-9999.99’));
/ PIC指定で、符号、桁数、小数点位置を正確に制御します。 /

/ 文字列を左寄せ、右側空白埋め、固定長で出力 /
PUT SKIP EDIT(‘String: ‘, STR_DATA) (A, X(8), A(15));
/ 文字列はデフォルトで左寄せ、右側空白埋めになります。 /

/ 総ゼロ抑制と通貨記号を使った出力 /
PUT SKIP EDIT(‘Amount: ‘, 123.45) (A, X(8), PIC(‘$$9,999.99’));
/ 123.45 が $123.45 と出力されます。カンマも挿入されます。 /

/ パック10進数の内部表現を理解するための出力（後述のバグに繋がる可能性） /
/ 直接EDITでパック10進数を出力するより、一度文字列に変換するなど工夫が必要な場合も /
/ ここでは直接EDITで試みて、挙動を確認します。 /
PUT SKIP EDIT(‘Packed Decimal: ‘, PACKED_DEC) (A, X(8), PIC(‘S9(5)V99’));
/ 注意: PIC指定でのパック10進数の直接EDIT出力は、コンパイラやバージョンによって挙動が異なる場合があります。 /
/ 実際には、STRIPやOVERLAYなどの関数で一時的な変換を行うことも多いです。 /

PUT SKIP LIST(”); / 空行を挿入 /

/ 改行制御の例 /
PUT EDIT(‘Line 1’); / 改行なし /
PUT SKIP EDIT(‘Line 2’); / 新しい行から開始 /
PUT PAGE EDIT(‘Page Header’); / 新しいページから開始 /

END MYPROG;

改行制御：`SKIP`、`PAGE`、そして`LINE`

`PUT`文における改行制御は、`SKIP`、`PAGE`、`LINE(n)`といったオプションによって行われます。

`SKIP`: 次の出力は新しい行から開始されます。引数なしの場合は1行スキップ、`SKIP(n)`とすると`n`行スキップしてから出力します。
`PAGE`: 次の出力は新しいページから開始されます。プリンター制御などの場面で利用されます。
`LINE(n)`: 次の出力は指定した行番号`n`から開始されます。

これらの制御を`EDIT`指定と組み合わせることで、帳票出力やログ出力など、レイアウトが厳密に求められる場面で、期待通りの結果を得ることができます。

動的メモリ操作とポインタ：移行時の隠れた落とし穴

PL/Iは、`BASED`変数とポインタを用いて、動的なメモリ管理を可能にします。これは、C言語のポインタ演算に似ていますが、PL/Iならではの型安全性や構造化されたアプローチが特徴です。

MYPROG: PROCEDURE OPTIONS(MAIN);

DECLARE
/ ベース変数（メモリブロックの基点） /
1 EMPLOYEE_RECORD BASED(EMP_PTR) ALIGNED,
2 EMP_ID CHAR(8),
2 EMP_NAME CHAR(30),
2 EMP_SALARY FIXED DECIMAL(10,2);

DECLARE
EMP_PTR POINTER, / ポインタ変数 /
ALLOC_SIZE FIXED BINARY; / 確保するメモリサイズ /

/ メモリの確保 (ALL) /
ALLOC_SIZE = 44; / EMP_ID(8) + EMP_NAME(30) + EMP_SALARY(10+2=12バイト相当) /
EMP_PTR = ADDR(EMPLOYEE_RECORD); / EMP_PTR を EMPLOYEE_RECORD のアドレスに設定 /
ALLOCATE EMPLOYEE_RECORD SET (EMP_PTR); / 指定されたポインタのアドレスにメモリを確保 /

/ 確保したメモリ領域へのアクセス /
EMP_ID = ‘EMP001’;
EMP_NAME = ‘John Doe’;
EMP_SALARY = 55000.75;

/ 確保したメモリ領域の内容を出力 /
PUT SKIP EDIT(‘Employee ID: ‘, EMP_ID) (A, X(10), A);
PUT SKIP EDIT(‘Name: ‘, EMP_NAME) (A, X(10), A);
PUT SKIP EDIT(‘Salary: ‘, EMP_SALARY) (A, X(10), PIC(‘99999999.99’));

/ メモリの解放 (FREE) /
FREE EMPLOYEE_RECORD; / 確保したメモリを解放 /
EMP_PTR = NULL(); / ポインタをNULLに設定（推奨） /

END MYPROG;

この動的メモリ操作は、可変長のレコード処理や、動的なデータ構造を構築する際に強力な威力を発揮します。しかし、移行プロジェクトにおいては、以下のようなリスクが潜んでいます。

ポインタの不正使用: NULLポインタ参照、二重解放、解放済みメモリへのアクセス（Dangling Pointer）などは、アベンド（ABEND）の主要因となります。
メモリリーク: `FREE`忘れによるメモリリークは、長時間稼働するオンラインシステムやバッチ処理において、徐々にリソースを枯渇させ、パフォーマンス低下やシステムダウンを引き起こします。
アライメントの問題: `ALIGNED`や`UNALIGNED`の指定、および`ADDR()`関数の使い方を誤ると、パフォーマンスの低下や、最悪の場合、データ破損につながる可能性があります。

これらの問題を回避するためには、コードレビューの徹底、静的解析ツールの活用、そして何よりも、アベンド発生時のダンプ解析能力が不可欠となります。

アベンド（ABEND）発生時のダンプ解析：犯人を特定する技術

基幹システムにおいて、アベンドは許されざる事態です。しかし、どんなに綿密に設計されたシステムでも、予期せぬ状況下でアベンドが発生する可能性はゼロではありません。アベンド発生時のダンプ解析は、その原因を特定し、再発防止策を講じるための最後の砦です。

ダンプ解析では、以下の情報を中心に調査を進めます。

1. アベンドコードと理由コード: ABEND S0C7（データ例外）、ABEND D37（ディスク容量不足）など、アベンドコードとその詳細を示す理由コードから、大まかな原因を特定します。
2. プログラムカウンタ（PC）とステートメント番号: アベンド発生直前のプログラムの実行位置を特定します。PL/Iでは、コンパイラリストのステートメント番号と照合することで、問題のコード箇所を絞り込めます。
3. レジスタ情報: 各レジスタに格納されている値から、変数やメモリ領域の状態を把握します。特に、ベース変数やポインタが参照しているアドレスは重要です。
4. ストレージダンプ: 指定されたアドレス範囲のメモリ内容をダンプ出力します。ここで、期待しない値が格納されていないか、データが破損していないかなどを確認します。
5. 呼び出し履歴（Call Stack）: プログラムがどのように呼び出されたかの履歴をたどることで、問題の発生源となった処理フローを特定できます。

移行プロジェクトにおいては、PL/Iプログラムだけでなく、DB2やCICSといったミドルウェアからの呼び出し、あるいはCOBOLなど他の言語との連携部分で発生するアベンドも考慮する必要があります。ダンプ解析は、これらの複雑な連携部分における問題の切り分けにも役立ちます。

パックデシマルの内部符号反転バグ：伝説のバグとその対策

PL/Iにおけるパック10進数（`PIC S9(…)`）は、その効率性から基幹システムで広く利用されています。しかし、特定のコンパイラバージョンや、特定の演算処理において、内部符号が反転するという、いわゆる「伝説のバグ」が存在しました。

このバグは、例えば正の数での除算結果が負の数として格納されてしまう、といった現象を引き起こします。原因は、パック10進数の内部表現における符号ビットの扱いの不具合に起因すると言われています。

対策としては、以下の方法が有効です。

1. コンパイラレベルでの回避: 最新のコンパイラを使用し、バグが修正されていることを確認します。
2. 明示的な符号チェックと変換: 演算結果を取得した後、その値が期待される範囲内にあるか（特に符号）、あるいはPL/Iの組み込み関数（例: `ABS`）を使用して絶対値を取る、といった処理を挟みます。
3. 一時変数への変換: 演算対象のパック10進数を、一時的に`FIXED DECIMAL`や`CHARACTER`型に変換してから演算を行い、結果を再度パック10進数に戻す、といった回避策も考えられます。

MYPROG: PROCEDURE OPTIONS(MAIN);

DECLARE
PACKED_NUM PIC S9(5)V99,
RESULT_NUM PIC S9(5)V99,
TEMP_CHAR CHAR(10);

/ 意図的にバグを誘発する可能性のある処理（例） /
PACKED_NUM = 123.45;
/ ここで、もしバグのあるコンパイラであれば、 /
/ RESULT_NUM = PACKED_NUM / 2; の結果が負になることがある /

/ 回避策：演算結果のチェック /
RESULT_NUM = PACKED_NUM / 2;
IF RESULT_NUM < 0 THEN / 符号反転バグの可能性を疑い、絶対値を取るなどの処理 / RESULT_NUM = ABS(RESULT_NUM); / ABS関数で絶対値を取得 / PUT SKIP EDIT('Result: ', RESULT_NUM) (A, X(10), PIC('S99999.99')); / 回避策：一時的な文字型変換 / PACKED_NUM = -987.65; / 複雑な演算を行う場合、一旦文字型に変換してから処理 / TEMP_CHAR = STRIP(EDIT(PACKED_NUM) (PIC('-99999.99'))); / EDITでフォーマットし、STRIPで空白除去 / / TEMP_CHAR を使って文字列として処理し、必要なら再度EDIT/FIXED DECIMAL等で変換 / / この例では単純化しています。実際には、より複雑な変換ロジックが必要になる場合があります。 / END MYPROG; このバグは、長年 PL/I を使ってきたエンジニアにとっては、ある種の「都市伝説」のようなものでしたが、実際に遭遇すると、原因特定に多大な時間を費やすことになります。移行プロジェクトでは、対象システムのコンパイラバージョンを正確に把握し、必要であればこのバグの回避策をコードに組み込むことを検討すべきです。

埋め込みSQL（DB2）とCICSオンライン処理のエッジケース対策

基幹システムは、DB2（あるいは他のデータベース）との連携、そしてCICS（あるいはIMS）のようなトランザクションモニター上でのオンライン処理が不可欠です。PL/Iプログラムにおいて、これらのミドルウェアと連携する際の「エッジケース」を理解しておくことは、移行の成否を分ける鍵となります。

DB2連携における注意点

データ型のマッピング: PL/Iのデータ型とDB2のデータ型（`CHAR`, `DECIMAL`, `FLOAT`, `GRAPHIC`など）との間で、予期せぬ変換エラーやパフォーマンス低下が発生しないよう、マッピングを正確に理解する必要があります。特に、`VARYING`文字列や`PIC`指定の数値型と、DB2の対応型との変換には注意が必要です。
カーソル位置とトランザクション: カーソルの位置（`FETCH`後、`UPDATE`/`DELETE`対象）を正確に把握し、トランザクションのコミット/ロールバックのタイミングと連動させることが重要です。コミット漏れや、解放されていないカーソルは、デッドロックやリソース枯渇の原因となります。
NULL値の扱い: DB2ではNULL値を扱いますが、PL/Iでは`DEFINED`句や`BASED`変数、あるいはNULL標識変数（Indicator Variable）を用いてNULL値を表現します。これらの連携がうまくいかないと、データ破損や意図しないロジック分岐が発生します。

CICSオンライン処理における注意点

画面入出力（BMS）: BMSマップ定義とPL/Iプログラム間のデータ受け渡しは、フィールド名やデータ型の一致が重要です。`PIC`指定の桁数不足や、`VARYING`文字列の長さ超過などは、エラーを引き起こします。
トランザクション制御（TCT）: トランザクションの開始、終了、一時停止、再開などの制御は、CICSの機能とPL/Iプログラムのロジックが密接に連携しています。特に、`ABEND`発生時の自動ロールバックや、異常終了時の画面復旧処理などを考慮する必要があります。
共有データ領域（TS/TDキュー）: CICSの`Temporary Storage Queue`（TS）や`Transient Data Queue`（TD）へのアクセスは、オンライン処理のパフォーマンスに直結します。不適切なアクセス方法（例: 頻繁な一時的な読み書き）は、システム全体の応答時間を悪化させます。`EDIT`指定を用いたフォーマット制御が、これらのキューへのデータ格納・取得においても重要となります。

これらのミドルウェア連携におけるエッジケースは、PL/Iの基本的な`GET/PUT EDIT`の知識だけでは対応しきれません。DB2のSQLリファレンス、CICSのアプリケーションプログラミングガイドといった、それぞれのミドルウェアのドキュメントと、PL/Iの言語仕様を照らし合わせながら、移行対象のコードを詳細に分析する必要があります。

まとめ：PL/Iの真髄を理解し、安全な移行を実現する

PL/Iの`GET/PUT EDIT`とフォーマット制御は、単なる入出力の手段ではありません。それは、基幹システムが要求する厳格なデータフォーマット、レイアウト、そして信頼性を実現するための、高度な言語機能です。

今回解説した、

`PACKAGE`, `PROCEDURE`, `OPTIONS(MAIN)`によるプログラム構造の理解
`EDIT`指定とピクチャ編集文字による柔軟なデータ整形
`SKIP`, `PAGE`による改行・ページ制御
`BASED`変数とポインタによる動的メモリ管理の注意点
アベンド時のダンプ解析による問題解決能力
パックデシマル符号反転バグのような、コンパイラ依存の特殊な問題への対応
DB2やCICSといったミドルウェア連携におけるエッジケース対策

これらは、PL/Iで構築された基幹システムを深く理解し、安全かつ効率的なレガシー移行を実現するための、まさに「生きた知識」です。

JavaやC#といったモダンな言語への移行は、多くの組織にとって避けては通れない道です。しかし、その移行を成功させるためには、移行元のシステム、すなわちPL/Iのこれらの奥深い部分への理解が不可欠です。今回解説した知見が、皆様の移行プロジェクトにおける一助となれば幸いです。PL/Iのコードは、単なる古いプログラムではなく、長年の運用に耐えうる堅牢な設計思想の結晶です。そのエッセンスを理解し、次世代システムへと昇華させていくことこそ、我々システムアーキテクトの使命と言えるでしょう。