ストアド・プロシージャーとは

見出しのアイコン

ストアド・プロシージャーとは ?

ストアド・プロシージャーとは SQL文による実行機能をプログラマブルに補完して
拡張できる機能のことです。

例えば、SQL文だけでは実行できる機能にも限界があり、
実行のパフォーマンスにも問題があります。
そこで SQL結果セットを作成できるような RPG、COBOL や C/400 を
予め作成して保管しておいて、これを呼び出すようにするとパフォーマンスにも優れた
柔軟性に富む処理を行うことができるようになります。
これらの予め登録されたプロシージャーのことをストアド・プロシージャーと呼びます。

ストアド・プロシージャーが動作する条件

ストアド・プロシージャーが動作するためには
RDBディレクトリーとして特殊値 *LOCAL と定義されている
ディレクトリーが登録されている必要があります。
このことは WRKRDBDIRE (RDB ディレクトリー項目の処理)コマンドによって
下記のように確認することができます。

解説

リモート・ロケーションが *LOCAL として定義されているRDBディレクトリーは
一般には i5/OS の導入時にシステムによって、'S'+(シリアル番号) の形式名で追加されています。
ストアド・プロシージャーを起動する ODBCドライバーは、
この *LOCALとして定義されているRDBディレクトリーを探してバインドします。
一般的には事前に *LOCALの RDBディレクトリーが登録されていますが
何らかの事情で登録がない場合は「1=追加」(ADDRDBDIRE:RDB ディレクトリー項目の追加)
によって *LOCALの RDBディレクトリーを登録してください。

クライアントからの要求を処理するプロシージャー

元々はストアド・プロシージャーは PCクライアントの ODBCドライバーからの
要求に応えて SQL結果セットを戻すことが本来の機能でした。

ODBCドライバーの処理

今ではストアド・プロシージャーは単に ODBCドライバーの要求を処理するための
サーバー・プログラムであるという役割となっています。

利用方法

ストアド・プロシージャーは Web での利用方法として

  • 動的なコンボボックス
  • 動的な POPUPウィンドウ
  • Webアプリケーション

に利用されています。

動的なコンボボックスや POPUPウィンドウにストアド・プロシージャーを登録しておいて
DDSソースにストアド・プロシージャーの名前を登録するだけでストアド・プロシージャーを
利用できるようになります。
このことは非常に便利な機能拡張となります。
従来型の 5250アプリケーションでは POPUPコード検索App を追加するには
POPUPコード検索プログラムを新規に開発して、それをまた親アプリケーションの
ひとつひとつにコーディングを追加する必要がありました。

しかし、コード検索用のストアド・プロシージャーは、プロシージャーを開発すれば
親アプリケーションの画面DDS に登録するだけで済みます。
ストアド・プロシージャー用の画面を開発する必要もありませんし、
親プログラムを一切、変更する必要もありません。
このように従来のアプリケーションを開発するのとは全く異なる簡単な手法だけで
機能を大幅に拡張することができるようになります。

またクライアント / サーバー型の適用業務で既に開発して使用していたストアド・プロシージャーは
Webアプリケーションのサーバー側のエンジンとして再利用することができます。

ストアド・プロシージャーの種類

ストアド・プロシージャーには

  • SQLストアド・プロシージャー
  • PGMストアド・プロシージャー
  • Query/400ストアド・プロシージャー

の 3種類があります。

最初の SQLストアド・プロシージャーとは SQL文を登録しておいて、
この SQL文から生成されるプロシージャーのことを意味します。

SQLストアド・プロシージャー

SQLストアド・プロシージャー は次のようにして開発 / 登録します。
最初に QSQLSRC などのソース・ファイルに次のような SQLステートメントを登録します。

QTRSRC/QSQLSRC(P1)

     CREATE PROCEDURE QTROBJ/P1() LANGUAGE SQL
       DYNAMIC RESULT SETS 1
         BEGIN
         DECLARE C1 CURSOR FOR
          SELECT TACODE, TTNAMJ FROM QTRFIL/TANTOM ORDER BY TACODE;
         OPEN C1;
         RETURN;
     END;

解説

初めの CREATE PROCEDURE QTROBJ/P1() によって、ライブラリーQTROBJP1 という
名前でプロシージャーを登録します。
実行する SQL文 SELECT TACODE, TTNAMJ FROM QTRFIL/TANTOM ORDER BY TACODE;
登録します。

RUNSQLSTM でコンパイル

次にこの SQLソースを RUNSQLSTM で実行すると、この SQL文を実行するプロシージャーP1
ライブラリー : QTROBJ に登録されます。
実際には上記の SQL文から C/400ソースが内部的に生成されてコンパイルされ、
生成されてできたプログラムがプロシージャーとして登録されることになります。
SQL文からの自動生成に頼るのではなくユーザーが SQL結果セットを
ODBCドライバーに戻すプログラムを作成するプロシージャーのことを次に紹介する
PGMストアド・プロシージャーと呼びます。

RUNSQLSTM でエラーのときは ?

RUNSQLSTM実行でエラーが発生してプロシージャーを作成できなかったときは、
入力やタイプ・ミスがないかを慎重に検討してソースを読み直してください。

  • 単純なスペル・ミス
  • セミコロン(;)などの漏れ
  • その他

対話式ジョブで RUNSQLSTM を実行したときであっても
印刷スプールに必ず RUNSQLSTM のコンパイル・リストと
エラー・リストの 2部が出力されていますのでそれを参照してください。

必ず ODBCドライバーを使ってテストしてください

ストアド・プロシージャーを作成したら必ず次の項で説明される
ODBCドライバー」を使ってテストした正しい結果が得られるかどうかご確認ください。
またストアド・プロシージャーの動作がおかしいと感じた場合も
ODBCドライバーによる確認をお奨めします。

PGMストアド・プロシージャー

SQLストアド・プロシージャーではユーザーは SQL文だけを記述して後は RUNSQLSTMコマンドによって
プロシージャーを実行するプログラムは内部で自動生成されるようになっていましたが
PGMストアド・プロシージャーでは実行プログラムはユーザーがソースから作成することになります。

PGMストアド・プロシージャーは開発は概ね、次の手順に従ってなされます。

  1. SQLRPGI などの SQLバインドの RPG や COBOL の作成 & コンパイル
  2. 対話式SQL または SQLソースに CREATE PROCEDURE文を仕込んで RUNSQLSTM で実行

です。

次の「ユーザー独自のプログラムの作成」では実際の RPG によるストアド・プロシージャーの開発方法を
具体的な事例に基づいて解説します。

Query/400ストアド・プロシージャー

Query/400ストアド・プロシージャーとは Query定義 (*QRYDFN) から生成される
ストアド・プロシージャーです。
既存のQuery/400定義(*QRYDFN)から


                       ストアドプロシージャーの作成  (CRTSQLPRC)

  選択項目を入力して,実行キーを押してください。

  ストアド・プロシージャー  . . . > P1             名前 , *NONE
    ライブラリー  . . . . . . . . >   QTROBJ       名前 , *LIBL
  タイプ  . . . . . . . . . . . . > *QRYDFN       *SQL, *RPG, *COBOL..
  プログラムまたは QUERY  . . . . > QRY001         名前 , *PROC
    ライブラリー  . . . . . . . . >   QTROBJ       名前 , *LIBL
  既存のプロシージャーの置換え    > *YES          *NO, *YES


のようにして CRTSQLPRC によって ストアド・プロシージャーを生成することができます。

Query/400を使えば複雑な選択条件であっても対話式の Query によって簡単に作れて わかりやすく保守も容易になります。