READ でファイル
LSHOHNS を LOOPして読み取って品種コード
SHSCOD が前に読んだ
レコードの
SHSCOD と異なるかどうかを絶えず検査して、異なっていてしかも、最初でない
場合だけに
小計を出力するように自己制御しているCOBOL的な記述となっている。
これは例が品種コードだけの切れ目を検査するという簡単なものであるが
レベルが
置き場コード、担当者コード、品種コード、... のように深い階層であれば
大変な作業となる。
しかも小計と改ページが同時に起こるような場合とかの例外事項までを
すべて考慮すると
なると、気が遠くなるばかりである。
演算の順序を見ても
となっており、これは素直は思考回路とは一致しないであろう。
メイン・アルゴリズムがこのようになっていると、ほんの少しを修正するだけでも
たちまちバグの
発生要因となる。最初に記述する開発者にとって一見、わかりやすいものと
写るのかも
知れないが、将来に渡る多くの危険分子を秘めているプログラムであると
言わざるを得ない。
ファイル仕様書の記述が
IF ではなく
IP (Input Primary) であることに注意。
RPGサイクルを使用する場合は
IP と指定すると
READ しなくても自動的に
IP として
指定したファイルが順に読み込まれてくる。
IS (Input Secondary) としての指定した別のファイルがあれば IP のファイルの
レコードを
すべて読み終えると次に
IS のファイルのレコードが読み込まれる。
マッチングを指定すると IP, IS を交互に読むことも可能である。
0010.00 I@SHOHIN 01
0011.00 I SHSCODL1
によって
SHSCOD の内容に変化があれば、標識
L1 が
ON になる。
これは別の例で
I CODE01 L3
I CODE02 L2
I CODE03 L1
が指定されたとすると CODE02 や CODE03 に変化がなくても CODE01 にさえ
変化が
あれば
L3, L2, L1 はすべて
ON になる。
つまり
Ln が ON になれば下位の
Ln-1, Ln-2, .... は
すべてON になる。
このことがプログラマーが余計な例外データの場合を考慮しなくても済むように
なっている
スグレモノであるといえる。
0033.00 C* ( 小計印刷 )
0034.00 C*----------------------------------------------------+
0035.00 CL1 SETON 43 |
0036.00 CL1 EXSR OUTPUT | 小計印刷
0037.00 CL1 ADD SHOKEI GOKEI 90 |
0038.00 C*----------------------------------------------------+
0039.00 C*( 合計印刷 )
0040.00 C*----------------------------------------------------+
0041.00 CLR SETON 49 |
0042.00 CLR EXSR OUTPUT | 合計印刷
0043.00 C*----------------------------------------------------+
に見られる制御レベルに L1, L2, ... LR で記述した行はレコードを最初に
読み込んだときは
実行されない。次に読み込もうとしたデータが異なる品種コード
であった場合に、はじめて
合計処理つまり一群のまとまりの終わりの処理としての
記述を行うことになる。
このように演算をRPGサイクルでは
合計演算 と呼ぶが、合計演算では次のレコードの
内容
はまだ読み込まれていない。例えば小計行に品種コードを印刷する必要が
ある場合であれば
最初の例であれば
BEFHNS という前のレコードのフィールド値を
保管しておいて、これを印刷
する必要があるが、RPGサイクルでの合計演算では
まだフィールド値は次のレコードの
フィールド値には変わっていないので
SHSCOD の値をそのまま印刷するだけでよい。
この結構便利な機能が最初は感覚的になかなか理解することができない。
処理自身は見ておわかりのとおりにRPGサイクルでは大変スマートで
まとまりの良いものに
仕上がっている。
将来への拡張に備えても信頼性の高いプログラムになっている。