別の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の処理が実行される。下記はその様子である。