別のJOBをあたかも自分のJOBとしてディバッグするにはサービス・ジョブという手法が
必要になる。
しかしサービス・ジョブを使用するには実行されるJOBのJOB番号などの識別がわかって
いなければならない。
バッチJOBであれば投入して暫く待機させるようにしてからJOB番号などを調べることが
できるが CGI ではそうはいかない。HTTPサーバー配下のどのスレッドを使用するかを
決定するのはHTTPサーバーのみぞ知るということになるので、一般的に複数のスレッド
を抱えているHTTPサーバーでは、どのスレッドで実行されるのかを予め予測することが
できない。
そこで IBM HTTPサーバーであれば

1. CHGHTTPA (HTTP属性の変更) で「サーバー・ジョブの最大数」を 1 に絞ってから
   HTTPサーバーを再起動する。
2. WRKACTJOB によってサブ・システム QHTTPSVRのDEFAULTインスタンスの
   PGM-QZHBHTTP (これがHTTPサーバー) 以外のもうひとつのJOB番号などを控えておく。
3. サービス・ジョブを開始する。(STRSRVJOB)
STRSRVJOB JOB(xxxxx/xxxxx/xxxxxx) によって今、控えたJOBのサービス・ジョブを開始する。
4. ディバッグを開始する。
   STRDBG MYLIB/MYPGM UPDPROD(*YES)
5. ブラウザを起動して CGI を呼び出す URL を打鍵する。
6. 対話式ソース・ディバッグが開始される。

先のCGIディバッグの方法について、もう一度考慮してみよう。
先のディバッグの方法では HTTPサーバーの最大スレッド数を 1にしなければならないことが
最大の問題である。
容易に想像がつくようにこの方法は本番稼動後には行えない。
既にWebシステムが本稼動している場合ではスレッド数を1に絞るということは業務を停止
させるのと同じである。
またCGIはHTTPサーバーのひとつのスレッド内で同時に複数が併行して実行することは
できないので、これまた複数の開発者が同時にディバッグを行うことはできない。
誰かがディバッグ中であれば、別の開発者は前の人のディバッグが終了するまでは
待たされることになる。
従ってご紹介はしたものの、一般のCGI のディバッグは

• 本稼動が開始されていないこと
• ディバッグする開発担当は一人だけであること

という極めて現実的でない条件がついてしまう。

EnterpriseServer では各開発担当が各人のエミュレータ内でHTTPサーバーを
使わずに、PCOMM 上だけでディバッグ可能な「STRCGIDBG」というディバッグ用の
コマンドが既に Ver1.0 から提供されているが Ver3.0 ではILE-RPGの利点を生かした
対話式ソース・ディバッグ機能としてコマンド WTRWEBDBG が追加された。
これは

• HTTPSVR 「ALASKA」の配下でディバッグJOB が本番と同じように実行される。
• 本稼動中であっても本番用とは別のインスタンス PGMR を起動してその中で実行させることができる。
• 複数スレッド、複数開発者が同時並行してディバッグが可能
• ディバッグ処理が極めて簡単

というスグレモノである。
操作は至ってカンタンであり、HTTPサーバー ALASKAが起動されている状態で

STRWEBDBG MYLIB/MYPGM + [実行]

とするだけで上記の2〜6の処理が実行される。下記はその様子である。