監視機能を活用する
IBM i には、メッセージを使用して情報をログ記録する素晴らしい機能があります。メッセージは、メッセージ待ち行列、ヒストリー ログ、およびジョブ ログに送られます。IBM i のジョブ ログは、アプリケーションの問題を識別し、解決するのに非常に便利に利用できます。ジョブで起こったことを調査するための、これほど素晴らしいロギング機能を備えているシステムは他にありません。
断続的に発生するアプリケーションの問題をデバッグする必要があるとしたらどうでしょうか。症状がジョブ ログに記録されるメッセージであるとしたらどうでしょうか。そして、このメッセージが送られ得る何百ものジョブがあるとしたらどうでしょうか。ジョブ ログに送られたメッセージを調査する方法には、ジョブ ログを手作業で調べる、メッセージ処理APIを使用する、あるいはQSYS2.JOBLOG_INFOサービスを使用するなど、さまざまなやり方があります。APIまたはIBM i サービスを使用して作業を自動化することもできますが、どちらも目的のメッセージを識別し、捕捉するためのツーリングの構築を必要とします。このやり方の最も深刻な欠陥は、それが事後であることです。すなわち、エラーはすでに発生しまっているということです。メッセージは見つかるかもしれませんが、エラーの時点で追加の診断データを必要とするとしたらどうでしょうか。
このオペレーティング システムは、ジョブ ログにメッセージが送られると同時に識別してすぐにアクションを取るための簡単な方法を提供しています。これはイベントの監視機能（Watch for Event）というもので、私は略して「監視機能」と呼んでいます。監視機能を、デバッグ時に使用される監視条件と混同してはなりません。それらは、2つの異なるものです。
監視機能はメッセージの発生を監視（watch）し、そのメッセージが監視された場所に送られたときに通知されるという非常に効率的な手法です。監視機能は、発生する可能性のある問題に関連するメッセージを簡単に見つけるのに役に立つ強力な診断ツールと言えます。メッセージ待ち行列、ヒストリー ログ、そして、この記事で取り上げているジョブ ログに送られるメッセージを監視できます。
監視機能の大きな利点は、その効率性です。監視機能は、APIやIBM i サービスのようにジョブ ログ全体を読み取ることはしません。というより、監視機能はオペレーティング システムのメッセージ処理コンポーネント内の出口点として実装されます。監視機能がセットアップされると、メッセージ処理コンポーネントはメッセージが送信されたときに監視機能をチェックします。これはクイック チェックであり、監視条件が一致しない場合、ロジックは通常通りに続行します。何らかのオーバーヘッドが発生するのは、監視された条件が一致するときだけです。パフォーマンスに影響を及ぼすことなく、システムのすべてのジョブを監視することが可能です。
監視プログラムは、異なるジョブ、つまりQUSRWRKサブシステムで稼働するQSCWCHPSという事前開始ジョブで呼び出されます。このQSCWCHPS事前開始ジョブ項目は、システムに付属しているものです。出口プログラムが完了した後、QSCWCHPSジョブは終了し、再使用はされません。
監視条件が一致した場合、メッセージが送られたジョブは、監視プログラムが実行中であること意識することなく続行されます。プログラムのロジックでは、監視された条件からの何らかのオーバーヘッドが発生します。断続的に発生する困難な問題をデバッグしようとしている場合に、監視プログラムは自動的にアクションを実行することができます。たとえば、ジョブを中断、ジョブをダンプ、*PRINTにジョブログを表示、ジョブをサービスおよびトレース、手動で対処するために誰かにメールを送信など、希望するどのようなアクションでも実行することが可能です。
STRWCH（Start Watch、監視の開始）コマンドは、メッセージの監視機能をセットアップします。以下の例では、任意のQZDASOINITまたはQSQSRVRジョブのジョブ ログに送られる、30以上の重大度のすべてのSQLメッセージを監視します。
STRWCH SSNID(WATCHSQL)
WCHPGM(MYLIB/WATCHPGM) CALLWCHPGM(*WCHEVT)
WCHMSG((SQL* *NONE *MSGDATA *ALL *GE 30))
WCHMSGQ((*JOBLOG))
WCHJOB((*ALL/*ALL/QZDASOINIT) (*ALL/*ALL/QSQSRVR))監視機能のセットアップ時にWCHMSG基準を使用すると、はるかに高度な監視を実行できます。たとえば、比較データが*FROMPGMまたは*TOPGMに一致する必要があることを指定したり、一致する必要があるメッセージ置き換えテキストのデータを指定したりすることができます。比較テキストは大文字小文字が区別され、大文字小文字を維持するために引用符を使用することができます。
MYLIB/WATCHPGMというイベントの監視出口プログラムを作成することができます。このプログラムは、いくつかの入力パラメーターを指定して呼び出しますが、その1つにイベント データがあります。イベント データには、監視されているメッセージおよびそのイベントが発生したジョブについての情報が含まれています。これにより、エラーについてのかなりの情報を収集することが可能になり、プログラム的にどのようなアクションを行いたいか決めることできます。IBMでは、2つの出口プログラムのサンプルを提供しています。1つは、IBM i Knowledge Centerの「イベントを監視する出口プログラム」であり、これはCで書かれたものです。また、IBMロチェスター サポート センターには、CLのサンプル、「STRWCH - Watch Exit Programs Explained with CL Example」も掲載されています。
IBMは、オペレーティング システムのService Monitor機能のために監視機能を使用します。WRKWCH *SRVMONコマンドを使用して、これらの監視機能をチェックすることができます。これらの監視機能の詳細情報を見てみると、複数の監視機能がシステムのすべてのジョブ ログを監視していることがわかると思います。以下の例では、システムがすべてのジョブ ログについてCPD1144メッセージ（「ジョブ ログ サーバーでエラーが発生しました。」）を監視していることが示されています。IBMでは、このエラーが発生した場合、診断データ付きで問題ログが生成されるようにしています。
Message ----Message queue----- -------------Job--------------
Message type Name Library Name User Number
CPD1144 *ALL *JOBLOG *ALL *ALL *ALL
また、監視機能は、PAL（Product Activity Log、製品アクティビティー ログ）項目またはLICLOG（Licensed Internal Code Log、ライセンス内部コード ログ）項目を監視することも可能にします。もっとも、これら2つを使用するのは、おそらく、断続的に発生するシステムの問題についてIBMとともに作業する場合のみと思われます。
監視機能は、V5R3のオペレーティング システムで初めて追加されました。初期リリースでは、監視機能は、STRTRC、STRCMNTRC、TRCCNN、TRCINT、およびTRCTCPAPPなどのトレース ツールと関連付けられていましたが、V5R4で独立した機能となりました。非常に長い間、備わっていたのにあまり使用されることのなかった、この秘宝とも言うべき機能をぜひとも活用してみてください。
