サーバー ジョブ (ODBC/JDBC のデータベース サーバー インスタンスなど) は、システム ユーザー プロファイルの下で実行されます。ストアド プロシージャの場合、システム ユーザーは通常 QUSER です。ジョブ内で作成されたオブジェクトは通常、ジョブ ユーザーが所有します。
サーバー ジョブは通常、他のユーザーに代わって作業を実行します。接続を確立するときに、サーバー ジョブにどのユーザーかを伝えます。(また、特定のサーバー ジョブは、その存続期間中に多くの異なるユーザーに代わって機能する可能性があることに注意してください。)
特にスプールされた出力の場合、これは問題です。これは、スプール サブシステムが「Web」よりも長く存在し、リモート データベースに多数のユーザーが接続する前に存在しているためです。ユーザーからユーザーへの切り替えの動作は、単にスプーリング サブシステムの構成の一部ではありません。また、IBM などのベンダーは、特定のジョブ ユーザーまたは接続ユーザーがいつスプール ファイルを所有する必要があるかを判断することもできません。(また、スプーリングはデータベース接続の主要な要素ではありません。)
IBM は、「切り替えられたユーザー」出力をQPRTJOB という名前のジョブで収集するようにデフォルト設定することで、スプーリングが出力をユーザーに関連付ける方法を適応させましたが、後の RPG プログラムで出力を処理する方法には完全には適合しません。
ただし、スプールされた出力を生成するストアド プロシージャを作成すると、そのプロシージャは出力の所有者を選択できるため、出力を同じジョブ内に保持することを選択できます。iSeries ナビゲーターの「SQL スクリプトの実行」機能に貼り付けることができる、以下の CALL の例を検討してください。
call qsys2.qcmdexc ('OVRPRTF FILE(*PRTF) SPLFOWN(*JOB) OVRSCOPE(*JOB)' , 48);
call qsys2.qcmdexc ('DSPMSGD RANGE(CPF9899) MSGF(QCPFMSG) OUTPUT(*PRINT)' , 51);
call qsys2.qcmdexc ('DLTOVR FILE(*PRTF) LVL(*JOB)' , 28);
これらをセットとして実行すると、CPF9899 のメッセージ記述の属性を示すスプール出力が作成されます。後で確認すると、QUSER が現在 QPMSGD という名前のスプール ファイルを所有しており、それがリモート データベース要求を処理している QZDASOINIT ジョブ内にあることがわかります。その場合、そのジョブ内の RPG プログラムは「*LAST」スプール・ファイルを簡単に見つけることができます。また、最初と最後の CALL を削除して、中間の CALL だけを実行すると、次のスプール ファイルを所有していることがわかります。
(QUSER は IBM のデフォルトです。ご使用のシステムが別のユーザー・プロファイルを使用している場合は、そのユーザーを「QUSER」に置き換えてください。)
おすすめ:
SP を変更して、ジョブでキャプチャーする必要がある出力をスプールする前に適切な OVRPRTF コマンドを発行し、出力が生成された後に DLTOVR を発行します。
ここに示したようなコマンドを使用して、テスト手順を作成できます。さまざまな OVRSCOPE() 設定と FILE(*PRTF) または特定の名前のファイルを試してみてください。また、オーバーライド コマンドの前後に出力を作成して、それらの動作の違いを確認します。
SP の終了後にサーバー ジョブが別のユーザーを処理する可能性があることに注意してください (または、別の SP がジョブの後半で呼び出される可能性があります)。そのため、DLTOVR が実行されていることを確認する必要があります。(これが OVRPRTF の近くに保つ理由の 1 つです。)