（※このトピックスは、Valence開発元（米CNX社）のブログ記事を翻訳・再編集したものとなります。原文記事は、コチラとなります。）
本番環境に展開したプログラムにエラーが存在しないことを保証することはかなり困難です。
QAチームが事前に綿密なテストを行ったとしても、あるプログラムが本番環境で予期せぬ動作をし、デバッグが必要となる場合があります。
ValenceのようなマルチスレッドのCGI環境でそのような問題が発生した場合、5250ベースのSTRDBGセッションを使っていると、問題を確認するためにデバッグするジョブを選択するのは難しいかもしれません。
「開発」または「テスト用」の Valence インスタンスでは、バックエンドへのリクエスト処理が少ないため、どの CGI ジョブが呼び出しを処理するかを特定するのは容易です。
2011年のValenceフォーラムの投稿にあるように、呼び出しを処理するCGIジョブのサービスジョブを開始(STRSRVJOB)することで、作成したプログラムのデバッグセッションを開始し、デバッグ処理を進めることができます。
しかし、本番環境で発生するロジックの問題に対処する場合は別です。
本番環境では、何十人もの異なるユーザーが、バックエンド(IBMi)に次々とリクエストを送信している可能性があります。
このような環境では、どのCGIジョブが原因となるプログラムの呼び出しを処理しようとしているのか、推測するのは困難です。
もちろん、RDi を使ってデバッグ作業を行う場合、このシナリオのサービスエントリポイントを設定するのは比較的簡単です。デバッガは、希望するブレークポイントにおいて、特定のユーザーのために適切な CGI ジョブを自動的に取得してくれます。
しかし、プログラムロジックを掘り下げるためのインタフェースが5250ベースのSTRDBGであったり、RDiが使用できない場合、デバッグセッションを特定するのは大変困難です。
この問題については長年の悩みでしたが、私たちは、STRDBGコマンドと5250セッションでサービス・エントリー・ポイントを設定できることが分かりました。
このコマンドは、特定のユーザー・プロファイルを使用してプログラムを実行するすべてのジョブに対して、プログラムの特定の行にサービス・エントリー・ポイントを作成します。
唯一の注意点は、サービス・エントリ・ポイントを発行するための5250セッションと、実際にデバッグ・プロセスを開始してプログラムを実行するための5250セッションを別々に起動する必要があることです。
しかし、たくさんのバックエンド処理が実行される本番環境で、STRDBG を使用してデバッグを実現する場合には、わずかな代償と思います。
以下がその手順となります。
(1)セッション #1 でサービス・エントリ・ポイントを確立する。最初の 5250 セッションで STRDBG コマンドを使用して目的のプログラムを選択し、対話的に実行中のプログラムのデバッグを開始するのと同じ方法で、このプロセスを開始します。プログラムにアクセス後、特定の行に、F6 キーや break コマンドを使用して、ブレークポイントを設定するのではなく、下記コマンドを使用してサービス・エントリー・ポイントを設定します。
sbreak [line#] user [ユーザーID]。
もちろん、ここでの[line#]はサービス入力ブレークポイントを設定したい行番号に置き換え、[ユーザー ID]はValenceでプログラムを呼び出すIBM iユーザー・プロファイルに置き換えます。呼び出しをトリガーするのと同じValenceプロファイルでログインしている場合は、userパラメータを省略することができます。また、いくつかのキーストロークを減らしたい場合や、IBM i 開発者にデバッガ・ショートカットを設定したい場合は、「sbreak」の代わりに「sb」という省略形を使用することも可能です。
(2)Valenceアプリでプログラム呼び出しをトリガーし、ブレークメッセージのためにセッション#1を監視します。ステップ1でSBREAKエントリーを確立したユーザーは、プログラムが呼び出されるために必要なアクションをブラウザから実行する必要があります。プログラム内で目的のブレークポイントに到達すると、サービスエントリーポイントがトリガーされたことを示すブレークメッセージが表示されます。メッセージの上にカーソルを置き、Help（またはF1）を押して、メッセージの詳細を表示します。
詳細テキストにあるSTRSRVJOBコマンドをコピーしてください。次のステップで使用します。
(3)セッション#1のブレークメッセージからコピーしたジョブ情報を使って、セッション#2でサービスジョブを開始 します。先ほどコピーしたSTRSRVJOBを、セッション#2の5250端末セッションのコマンドラインに貼り付けます。
(4)セッション#2 で別のデバッグセッションを開始し、「実際の」デバッグを行います。セッション#2のターミナル・セッションで同じプログラムに対して STRDBG コマンドを再び発行し、必要に応じて適切なライブラリ名でプログラムを修飾します。プログラム内でプロダクション・ファイルが更新用に開かれている場合に例外メッセージがトリガされないように、コマンドのオプションにUPDPROD(*YES)を必ず含めてください。このセッションは現在、目的の CGI ジョブに対応しているため、最初の 5250 セッションでデバッガを「一時停止解除」すると、アクションを受信する準備が整います。
(5)セッション#1で一時停止していたジョブを解除し、セッション#2でデバッグを開始します。 sbreakコマンドを発行した最初の5250セッションに戻り、ENTERを押します。
5250のセッション#2は、sbreakコマンドで指定した行から始まるおなじみのデバッギング・セッションにポップアップするはずです。これで、あなたのプログラムの論理的な問題の真相を突き止めることができます。
この時点で、セッション#1の 5250 セッションは不要になります。セッション#2でのデバッグが終了したら、必ず ENDDBG コマンドを発行してデバッグ・セッションを終了し、ENDSRVJOB を発行してサービス・ジョブを解放してください。
最初のセッションで発行されたサービス・エントリ・ポイントは、セッションを終了するか、ENDDBGコマンドを発行するまで有効です。 まだ有効な場合は、ステップ2からこのデバッグ処理を再度繰り返すことができます。
多くの人が苦労して学んだように、手順 4 で STRDBG コマンドにオプションUPDPROD(*YES) を指定し忘れると、コールスタック内の任意の場所でプロダクション・ライブラリの追加または更新のためにファイルが開かれた場合にデバッグ・セッションで致命的な例外が発生し、すべてのプロセスをやり直すことになります。
コマンドのデフォルトオプションを設定するための権限がある場合は、次のようにSTRDBGコマンドのデフォルトを変更することで、オプションを設定し忘れることを避けることができます。
chgcmddft cmd(strdbg) newdft('updprod(*yes)')
Zoomにてで、5250デバッガの「高度なテクニック」を紹介してくれた、フォーラムユーザーのDanM氏に深く感謝致します。