CL と RPG プログラムの組み合わせを使用して作成されたストアード・プロシージャーがあります。iSeries でローカルに呼び出された場合は、すべて問題ありません。外部から (たとえば、SQL フロントエンドから) 呼び出された場合、RPG プログラムは生成したスプール ファイルでハドルを取得できません。これは、スプール ファイルが別の (ランダムな?) ジョブ番号とユーザーの下に表示されるためです。ジョブは QUSRWRK サブシステムで QUSER として実行されますが、スプール ファイルは接続プール (つまり USERA) で外部的に接続が行われたユーザー ID を取得します。
ジョブの実行時に正しい sppol ファイルのハンドルを確実に取得できる方法はありますか (そのキューから最後のスプール ファイルを選択するなどに依存するのではなく)。
ストアード・プロシージャーを実行している（ジョブQZDASOINITで実行している）場合、プログラム状況データ構造を介してスプール出力にアクセスすることはできません。これらのスプール・ファイルは、user / QPRTJOBという名前のジョブにあります。ここで、userは、ストアード・プロシージャーを実行している「現在のユーザー」です。スプール・ファイルにアクセスするには、api QSPRILSPを実行して、スプール・ファイルを指す構造を取得します。
動作とAPIの両方は、IBMのインフォセンターで十分に文書化されています。
サーバー ジョブ (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 つです。)
ジョブ自体は知っているか、見つけることができるので (以前の回答を参照)、他のすべてが失敗した場合は、必要な情報を提供するキューにメッセージを配置するようにプログラムを変更します。暇つぶしに読んでください。
.
RPG プログラムを変更できる場合は、プログラム状況データ構造からジョブ情報を取得できますが、ファイル情報データ構造にはオープン・フィードバック域からのスプール・ファイル番号があります。ただし、ジョブ情報がQUSERジョブ（必要なものではない）またはUSERAジョブ（必要なもの）用になるかどうかはわかりません。スプール ファイル番号は、後続の印刷 API呼び出しのハンドルとして十分である可能性があります。