サブ・ファイルに関しては誤解と都市伝説が非常に多いので
もう一度良く確認して、しっかり理解しておきたい。
1. SFLSIZ と SFLPAG を同じ値で定義する。
これは IBM 「アプリケーション対話プログラミング」とか
「適用業務画面プログラミング」の
解説が非常にわかりにくい表現であり多くの読者に誤解を与えているために
SFLSIZ と SFLPAG を同じ値に設定する人がかなり多い。
【例】
A SFLSIZ(0014) A SFLPAG(0014)
という具合である。
このときエンド・ユーザーがロール・アップ・キーを押すと
プログラムは
- 1.
SFLCLRしてから - 2. SFL レコードを追加する (もちろん最大
14レコード以内とする)
さらにエンド・ユーザーがロール・ダウン・キーを押すと
プログラムでは
- 1.
SFLCLRしてから - 2.
READPで最後の行から前に戻りつつ SFL レコードを出力するか、
またはSFLPAGの分だけREADPしてから
改めてREADでSFLPAGの分だけ読む。
という恐ろしく複雑な工程をとらなければならない。
プログラマーは、ここで「これはおかしい ?!」と気づいて欲しいのだが
「このような不便さが要るのだろう」と思ってしまうのは問題である。
したがってどういう理由があれ SFLSIZ = SFLPAG とする合理的な理由は
見当たらないのだが IBM マニュアルにこのケースが紹介されていて
その問題点が IBM によって的確に指摘されていないので
このようなケースでの書き方が未だにある。
2. SFLCLR と SFLINZ の違いがわからない。
これも初心者によくある誤解で SFLCLR と SFLINZ の区別がついていないケースである。
SFLCLR とはファイル(サブ・ファイル)の中身をクリヤーする、
つまり CLRPFM のように空の状態にすることである。
SFL レコードを追加する最初には SFLCLR しておくべきである。
一方、SFLINZ とはファイル(サブ・ファイル)の初期化であり、サブ・ファイルの中を
すべてブランク・レコードで埋め尽くす、という作業を行うことである。
ファイル形式で言えば、このようなファイルのことを「ダイレクト・ファイル」と呼ぶ。
ファイルに対する入出力のパフォーマンスは
レコードの追加よりもレコードの更新のほうが圧倒的に速いので
ハード・ウェアが遅い昔では意図的にダイレクト・ファイルを
使用する業務も設計されていたが
ハード・ウェアの処理速度が十分速くなった現在では
ダイレクト・ファイルを使うことはほとんどない。
これと同じ理由で SFLINZ を使う理由は見当たらない。
しかし SFLINZ + UPDATE SFL レコードによって
SFL レコードを出力しようとしている例がある。
SFLINZ と SFL レコードを更新する方法はあえて紹介しない。
SFLINZ を使うと後の処理は、相当複雑なものとなる。
とにかくは動く、という理由で SFLINZ を使うことは直ちに中止したほうがいい
3. 正しい記述をすればロール・ダウンの記述の必要はない。
サブ・ファイルという構造は IBM が処理が便利になるように構造を工夫されている。
ロール・アップが要求されたときに
サブ・ファイル・レコードを追加という形で出力さえしておけば
ロール・ダウンの処理は i5/OS がプログラムに代わってやってくれる。
つまりロール・ダウンの記述を行う必要がない。
逆にロール・ダウンが記述されているプログラムがあれば、
それは正しいサブ・ファイル処理を行っているプログラムだとは言えない。
先の SFLPAG = SFLSIZ の記述も DSPF にしてしまうと
ロール・ダウンの記述が必要となってしまう。
4. SFLSIZ が SFLPAG より +1 であれば SFL は自動拡張される。
これは正しい都市伝説であり多くの経験豊かな開発者も
SFLSIZ を SFLPAG + 1 の値として設定しているはずであるが、
このことを記述した IBM のマニュアルは実は、どこにも存在しない。正確には
「SFLSIZ が SFLPAG より大きい場合は SFL は自動拡張される」と記述されている。
つまり +1 でなくても、とにかく SFLSIZ のほうが大きければ
自動拡張が行われることになる。
「大きければよい」ということで +1 して使用していることが現実のようである。
IBM の SE が開発者に +1 と指導した歴史が都市伝説として残ったのかもしれない。
SFLSIZ は SFLPAG + 1 ではなく、
正しくは SFLSIZ > SFLPAG であれば SFL は自動拡張される。
というのが正しい理解である。