こんなRPGを書いてはいけないその(4)

長いあいだ業界にいるといろいろな人の書いたRPGを見る機会が
多いがその中で誤解が多いのがSFL(=サブ・ファイル)の使い方である。

笑えないいくつかのエピソードを紹介しよう。
_

■ SFLBLKですべて埋めてから更新するSFLプログラム

これはある大手旅行代理店システムをサポートしている子会社が
作ったRPGプログラムであるがWeb化に移行するために相談を
受けた事例である。

非常に特殊なつくりになっている。
この会社のSFL入力/照会プログラムはすべて

(1) SFLBLKキー・ワードでDSPFのブランクのSFLレコードで埋める。

(2) SFLレコードを1レコードずつCHAINしてすべて更新していく。
これがこの会社のSFLレコードの追加という作業であるらしい。

(3)ユーザーがロール・アップ・キーを押すとまたブランクのSFLレコードを
1画面の行数分だけ追加する。

(4)追加したSFLブランクレコードをひとつずつCHAINしてから更新する。

　… おわかりだろうか?
すべてのSFLレコードはまずブランクのSFLレコードを追加してから
更新する。
従って READCなどは使えない。SFLレコードのWRITEによる追加もない。
すべてあるのはUPDATE SFLレコードだけである。

このような構造であるのでWeb化へ移行することはできなかった。
この会社ではこのSFLプログラムだけでなく
すべてのSFLを扱うプログラムがこのパターンで作成されていた。
トップ・クラスの旅行代理店のRPGである。

恐らくはSFLBLKの意味もわからずに試行錯誤でいろいろとやっていくうちに
この特殊な方法で動作したのでSFLとはこのように作るものだと
思って社内のすべてのプログラムがこうなって先輩から引き継がれてきたのだと
推測する。

昔はSFLなどなかったので配列を使って記述していた場代もあったことを
考えるとSFLは本当に効率が良くなったので正しい使い方をしたいものだ。
　　　まあこの会社の人は次のように考えたのだろう。
　
　　

(1)最初にSFLをセットするのは SFLBLK(=SFL Blank)だと考えた。

この人はブランクとクリヤーの区別がついていない。マニュアルを読むとブランク・レコードを追加すると
書いてあるからブランクとは空にする意味であると感じたのかも知れない。
SFLBLKはBLANKレコードでサブ・ファイルの中を埋め尽くすという意味である。空にするという意味ではない。
よくExcelの行と列の意味の区別がつかない人がいるがそれと同じでブランクとクリヤーの区別がついていないようである。
　　　　　もう少しマニュアルをきちんと読めば SFLCLR (=SFL Clear: SFLクリヤー)というキー・ワードを見つけるはずである。

(2)サブ・ファイルにRPGのWRITE命令でSFLレコードを追加しようとしたが当然エラーになるので

UPDATE命令でSFLレコードを更新しすると表示されたのでこれが正しいと思いこんだ。

(3)先輩から後輩へとこの誤りが引き継がれて社内で誰も誤りに気付く者はいなかった。

… ブランクとクリヤーの区別がつかない人に始まったのだろうがこれでもRPGは動作してしまう。
ちなみに社内でこの話をしたところSFLBLKキー・ワードはうちでは誰も知らなかった。
使う必要がないからである。

※その昔、AS400と呼ばれるまだ以前には直接ファイル(=ダイレクト・ファイル)と呼ばれているファイル構造があった。
これは最初にファイルにブランク・レコードをすべて埋め尽くしておいてから更新命令だけでレコードを追加する
手法であるがそれはアクセス・パフォーマンスを向上させるためであった。
レコードの追加は今でもパフォーマンスの低下の原因になるので当時は遅い処理をアプリケーションの工夫で
少しでも速くするためであったが今回のこのSFLBLKはこの手法とは無関係で単に開発者がブランクの意味を
理解していなかっただけのことである。

　　　参考までに多くのRPGプログラマーは最初にSFLCLRを実行してからSFLレコードを追加していると思うが
実はSFLCLRしなくてもSFLレコードを追加するだけで動いてしまうのだ。
このようにRPGは適当に書いても動いてしまうのである。
先に紹介した大手IBM特約店プログラマーでも適当にわからなくて
書いているうちに動いてしまう。
BASICやVBA, VC++ではこんなことは絶対に起こらない。
Javaでも極めて正確に書かないと動作しないしJavaのバグを知っていないと
開発もできない。

■ READC を知らないプログラマー

READC(=Read Change)とはSFLの入力系ではよく使うRPG命令である。
エンド・ユーザーが変更したSFLレコードだけを読取るのが READC命令である
パフォーマンス良く変更レコードだけを読取ることができる。

ところがREADCを知らないとひとつひとつのSFLレコードにCHAINしてレコードを
読取って判断するしかない。
全く不便な処理になってしまう。
あるソフト開発会社の社長さんにWeb化の指導をする機会があったのだが
READCを知らなかったらしくて説明すると「いつそんな命令ができたのですか?」と
聞かれる始末。
これには弱ってそのことをよもやま話として別の特約店の元SEにこの話をすると
「僕も知りませんでした」と言われてしまった。
恥をかかないためにもREADCくらいは教養として知っておきたいものである。