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