OPNQRYF で LF メタボの解消!?
- 2010年1月13日(水) 01:07 JST
-
- 投稿者:
- hidehi
-
「「論理ファイル」はもういらない!?」で、「選択/除外/結合の論理ファイルであれば OPNQRYF を使用することで RPG の書きかえはほとんどなしでもできます」と言いましたが、今回はそれを実際どうやるか、を見てみましょう。
OPNQRYF で選択/除外の論理ファイルを置き換えてシステム資源を有効に使おう!! というお話になります。
まず、以下のような SELECT/OMIT の入った論理ファイルを使用しているプログラムがあったとします。
A R JUMIDP PFILE(JUMIDP)
A K JHCHUB
A S JHKING CMP(GT 100000)
こちらがその論理ファイルを読んで出力するプログラムになります。ちなみに、EOL/400 に載っていた例題を ILE RPG で書き直したものです。
↑ の論理ファイルの定義に従って、JHKING が 100,000円以上のもののみが出力されます。（ちなみに物理ファイルは CREATE TABLE で作成し直したものにコピーして使っているのでレコード様式の RENAME を行っています。もともとの QEOL のテーブルを使っている場合に必要のないものですのでご注意を）
H DATEDIT(*YMD)
FSOLF IF E K DISK
F RENAME(JUMIDP:JUMIDR)
FQPRINT O F 132 PRINTER OFLIND(*INOF)
*
D YUCO S 2 DIM(5) CTDATA PERRCD(1)
D YUHO S 12 DIM(5) CTDATA PERRCD(1)
*
D i S 1 0
D YUSOHO S 12
*
/free
//見出し印刷
except MIDASI ;
//受注見出しファイルの読み込み
DoU (%EOF) ;
read SOLF ;
If (%EOF) ;
leave ;
else ;
exsr SR_MID ;
EndIf ;
EndDo ;
//終了処理
*inLR = *on ;
Return ;
BegSR SR_MID ;
i = %lookup(JHYUSO : YUCO) ;
if i <> 0 ;
YUSOHO = YUHO(i) ;
else ;
YUSOHO = *all'*' ;
endif ;
if (*inOF) ;
except MIDASI ;
reset *inOF ;
endif ;
except MEISAI ;
EndSR ;
/end-free
*
OQPRINT E MIDASI 02
O 6 'RPG050'
O 53 ' **** 受注一覧表 **** '
O 77 '作成日'
O UDATE Y 86
O 94 'ページ'
O PAGE Z 99
O E MIDASI 04
O 19 '得意先 受注'
O 73 '明細 送状 輸送'
O E MIDASI 05 07
O 19 '番 号 番号'
O 31 '受注日付'
O 49 '受注金額'
O 72 '行数 番号 CODE '
O 85 '輸送方法'
O E MEISAI 2
O JHTOKB 9
O JHCHUB 18
O JHDATE 30
O JHKING 49
O JHGYOS 56
O JHOKUB 65
O JHYUSO 71
O YUSOHO 88
**
10
20
30
40
50
**
店頭渡し
トラック便
貨車便
航空便
船便
SELECT/OMIT の論理ファイルがなぜあんまり好ましくないか、ですが、大きく以下の 2つの理由があります。
SELECT/OMIT の論理ファイルにはキーがあるため、元テーブルが更新されるたびにメインテナンスの負荷がかかります。
論理ファイルというものにはキーが必要な仕様になっているため、選択/除外したいだけでもキーが必須になっています。ここが SQL ビューと大きく異なるところですね。
これがひとつめの理由です。
プログラムを実行する直前に動的に選択すれば、元テーブルの更新時の負荷はかからなくなりますわけです。
V5R2 以降 V5R4 以前のシステムでは、SQL で元テーブルをアクセスした時に、
その元テーブルに SELECT/OMIT の論理ファイルがくっついているだけで、処理するデータベースエンジンが変わってしまいます。
最新式のもの（こちらの方が原則速いのでもちろんデフォルトです）から S/38 以来の旧式なものに再ルートされてしまいます。
これがふたつめの理由になります。
再ルートの時間ももったいないですし、速いもの（最新式のエンジン）から旧式のものに処理が移るので、パフォーマンスがよくなる確率は高くはありません。
つまり、SELECT/OMIT の論理ファイルというのは、今やパフォーマンスやシステム資源の有効利用という観点からは正直あまりメリットのないものなんです。
OPNQRYF というコマンドは、静的に、常時負荷のかかった"論理ファイル"という仕組みではなく、
必要な時に必要なデータを、動的に、まさしくオン・デマンドで取ってきて用意する、というために登場しています。
まさしく、メタボ化してしまった"論理ファイル"を救うためのコマンドなわけです。
非力だった S/38 には時期尚早な機能だったかもしれませんが、今はそんなことはありません。
さて、ではその使い方を見てみましょう。
OPNQRYF コマンドの QRYSLT パラメータに SELECT/OMIT の論理ファイルと同様の記述が可能です。
論理ファイルで↓ のように記述されるものは
A K JHCHUB
A S JHKING CMP(GT 100000)
↓ のように記述することができます。
DDS での K が KEYFKD パラメータに、S（選択）の記述が QRYSLT パラメータに移っているだけですね。
しかもこちらの方が SQL の WHERE 句での記述に近いため、今どきの人にはわかりやすいように思います。
OPNQRYF FILE((JUMIDP)) QRYSLT('JHKING > 100000') +
KEYFLD((JHCHUB))
OPNQRYF で必要なデータへのアクセスパスをセットアップした後にプログラムを呼び出せば、選択されたデータを元にプログラムは処理を行うことになります。呼び出す側の CL を変更するだけで、元データの条件をいろいろ変えることができます。同じことを SELECT/OMIT の論理ファイルでやろうとすると、
- 条件に応じた DDS の作成・コンパイル（それに伴ってディスクを食うオブジェクトもできてしまいますね …）
- その論理ファイルを指定したプログラムの作成・コンパイル（似たようなプログラムがたくさんできてしまいますね …）
というステップが必要になり、余計な手間がかかるのと将来のメインテナンスの心配が出てきてしまいます。
こちらが呼び出す CL プログラムの全文です。
OPNQRYF でセットアップしたデータをプログラムで共用オープンするために OVRDBF コマンドで SHARE(*YES) とします。
また、RPG プログラムが終了したら CLOF コマンドでファイルをクローズしておきます。
OVRDBF FILE(JUMIDP) SHARE(*YES)
OPNQRYF FILE((JUMIDP)) QRYSLT('JHKING > 100000') +
KEYFLD((JHCHUB))
CALL PGM(RPGLE050F)
CLOF OPNID(JUMIDP)
プログラムは F 仕様書と READ 命令の引数を元のテーブル（物理ファイル）に変更するだけです。
こうしておけば、元のテーブルの検索条件は呼び出し側の CL プログラムで OPNQRYF の QRYSLT を変更するだけで変えられるようになりますね。
H DATEDIT(*YMD)
FJUMIDP IF E K DISK
F RENAME(JUMIDP:JUMIDR)
FQPRINT O F 132 PRINTER OFLIND(*INOF)
*
D YUCO S 2 DIM(5) CTDATA PERRCD(1)
D YUHO S 12 DIM(5) CTDATA PERRCD(1)
*
D i S 1 0
D YUSOHO S 12
*
/free
//見出し印刷
except MIDASI ;
//受注見出しファイルの読み込み
DoU (%EOF) ;
read JUMIDP ;
（以下まったく同じなので省略します）
たいていの RPG プログラムは CL プログラムから呼ばれているものですし、（だいたい LF も毎回別メンバーを OVRDBF して使うこともけっこうありますよね）
そうでなかったとしても呼び出し用の CL プログラムをひとつ前に追加することは通常それほど難しいことではありませんね。
SELECT/OMIT の論理ファイルを OPNQRYF に変更することで、システム資源の有効利用やプログラムの自由度があがることによる有効活用の道が開けます。
昔マシンが非力だった時代（主に RISC 以前ですね）は、「論理ファイル」を用いて薄く広くシステム負荷を分散させることが有効だったわけですが、
今のその当時とは比較にならない CPU パワー（クロックなんてとんでもなくあがっていますしねぇ）を考えれば、
逆に今の世の中と同様の「必要な時に必要なだけ動的に用意する」というのが有効な手段だと思います。
つまり、論理ファイルがあると
－アクセスパスを保管するサイズが必要（OPNQRYF で動的にデータを取得すれば必要なくなる）
－更新に CPU / メモリのパフォーマンス負荷がかかる（OPNQRYF では動的にデータを取得する時にだけシステム資源（CPU / メモリ）が必要）
といったことがデメリットとして出てくることがあります。
論理ファイルは常時メインテナンスされているため、その更新負荷が日中のオンラインだったり夜間バッチだったりにのせられています。
ディスク上にスペースも取りますので、得てして気軽に作りすぎてしまった論理ファイルが思いもかけないシステム資源の浪費につながっていることもありますね。
RISC 以降飛躍的に速くなった CPU パワーによって、OPNQRYF で動的にデータを取ってくることは ↑ のような"メタボ"的な症状に対して相対的にコストが軽くなることがあるわけです。
ぜひともシステム資源は有効にお使いください!!
トラックバック
- このエントリのトラックバックURL:
- http://www.iforum.ne.jp/trackback.php/20100113010723417
この記事にはトラックバック・コメントがありません。
コメントは投稿者の責任においてなされるものであり，サイト管理者は責任を負いません。
ものすごく昔の話(S/38時代)ですが、データ数の多いPFに直接OPNQRYFを使用したアプリケーションを作ったことがあります。当時の非力なマシンではOPNQRYFだとパフォーマンスが出ず、結局LFを作成してそのLFにOPNQRYFをかけてパフォーマンスを改善しました。
今のマシンは当時とは比較にならないくらい高速になっているので同様の問題は発生しないかもしれませんが、巨大なPFを動的にSELECT/OMITするのはそれなりの負荷がかかる気がします。そういう状況も起こりうるという事を考慮しておくようお勧めします。
---
ここに書かれている内容は私の所属する会社、組織とは関係ありません。
内容を誰かが保証する物ではありません。