1. 導入：なぜ今、Report Writerなのか
ベテランの皆様なら、一度は「帳票の改ページ制御」や「合計行の集計タイミング」でロジックがスパゲッティ化した経験があるはずです。行カウンタを回し、ブレイクキーを判定し、合計行を印字して…といった処理を手続き型で書くと、保守性は著しく低下します。COBOLのREPORT SECTION（報告書節）は、これらの面倒なレイアウト制御を宣言的に記述できる強力な機能です。これを使いこなすことで、ビジネスロジックと帳票レイアウトを完全に分離し、堅牢なプログラムを作成できるようになります。
2. 基礎知識：宣言的記述の仕組み
Report Writerは、プログラムの静的構造として「どのような見た目の帳票か」を定義する機能です。
・RD（Report Description）：報告書全体の書式（行数や余白）を定義します。
・REPORT SECTION：DATA DIVISION内に記述し、物理的なレイアウトを構造化します。
・TYPE句：REPORT FOOTING（最終合計）、PAGE HEADING（頁見出し）、DETAIL（明細）などのタイミングを自動判定させるためのキーワードです。
手続き部では、明細データをセットして「GENERATE」命令を投げるだけで、改ページや合計出力が自動的に行われます。
3. 実装・解決策：構造的な定義の進め方
実装の肝は「RD句での論理定義」と「01レベルでの階層定義」です。
まず、RDでREPORT名と制御（CONTROLS ARE…）を定義し、どのデータ項目でブレイクさせるかを指定します。次に、各明細行や合計行を01レベルで記述します。これにより、PROCEDURE DIVISIONでは「どのタイミングで何を出力するか」という複雑な判定文を記述する必要がなくなります。
4. サンプルプログラム：実用的な帳票定義の雛形
以下は、明細を出力し、特定のキーで合計行を出力する際の構造例です。
DATA DIVISION.
FILE SECTION.
FD PRINT-FILE.
01 PRINT-REC PIC X(132).
REPORT SECTION.
RD SALES-REPORT
CONTROLS ARE SALES-ID.
- 頁見出しの定義
01 TYPE IS PAGE HEADING.
05 LINE 1 COLUMN 1 PIC X(10) VALUE “売上報告書”.
- 明細行の定義
01 DETAIL-LINE TYPE IS DETAIL.
05 LINE + 1 COLUMN 5 PIC X(10) SOURCE SALES-ID.
05 COLUMN 20 PIC ZZZ,ZZ9 SOURCE SALES-AMT.
- 合計行の定義（ブレイク時に自動出力）
01 TOTAL-LINE TYPE IS CONTROL FOOTING SALES-ID.
05 LINE + 2 COLUMN 5 PIC X(10) VALUE “合計:”.
05 COLUMN 20 PIC ZZZ,ZZ9 SUM SALES-AMT.
PROCEDURE DIVISION.
- 実際には各レコードの読み込みループ内で以下を実行する
- GENERATE DETAIL-LINE.
- これだけで改ページ制御と合計出力が自動化されます。
5. 応用・注意点：現場で陥りやすい罠
Report Writerを使用する際の注意点は、「手続き部との混在」です。
・柔軟性の限界：極端に複雑な条件分岐（特定行だけ罫線を引くなど）が必要な場合、Report Writerの制約にぶつかることがあります。その際は、無理をせず「WRITE命令を用いた手続き型出力」と使い分ける判断が必要です。
・初期化の徹底：合計行（SUM句）を使用する場合、ブレイク時の自動リセットは非常に便利ですが、意図しない値が残らないよう、レコードの初期化タイミングには注意してください。
・デバッグの難しさ：自動制御される分、出力タイミングのデバッグが難しくなりがちです。まずは小さなテストプログラムで、期待通りのタイミングで制御行（CONTROL FOOTING等）が出力されるかを確認することをお勧めします。
宣言的記述は、一度慣れてしまえば帳票プログラムの品質を劇的に向上させます。ぜひ次回の帳票開発で検討してみてください。
コメント