今回はユーザーアプリケーションやシステムプログラムがキャッチした特定のイベントをメッセージ待ち行列に送出して監視する方法についてご紹介します。
IBM i はユーザーアプリケーション内のMONMSGコマンド、Navigator for iモニター、システム応答リスト（WRKRPYLEコマンド）を参照するジョブ等で、特定イベントを検出しメッセージ待ち行列にメッセージを送出し監視させることが出来ます。
監視する特定イベントの例としてはアプリケーション実行時に発生するCPFxxxxなど特定のメッセージID監視、特定ジョブの開始・終了、X秒以上の間CPUの平均使用率がYY%以上を記録した等様々なイベントが設定できます。
QSYSOPR等メッセージ待ち行列を使用したMSG ID監視
今回ご紹介するのは、ユーザーアプリケーション(CLプログラム)にMONMSGコマンドを指定してエラーが発生したことをCLプログラムで検知し、メッセージ待ち行列にMSG IDを送出する方法です（図1）。
▲図1. ユーザープログラム(例CLP)によるユーザー作成メッセージキューへのメッセージ送信
ユーザー作成CLプログラム内にMONMSGコマンドを記述し、特定メッセージIDが発生した際、管理者の監視対象となるメッセージ待ち行列MSGQにメッセージが送出されます。
一般的なケースではメッセージ待ち行列QSYSOPRにメッセージを出力していると思われますが、この例のようにユーザーアプリケーション用に専用のMSGQ(例 USRLIB/USRMSGQ1）を作成し監視することも可能です。QSYSOPRメッセージ待ち行列では該当アプリケーション以外のメッセージも送出され煩雑になってしまいますが、専用のMSGQを使用することにより、該当アプリケーションに限定したメッセージ監視ができる点がメリットとなります。この例では1つのユーザージョブだけを表現していますが、複数のジョブから同じメッセージキュー(USRLIB/USRMSGQ1）にメッセージ送出し監視することも当然可能です。
補足）CLプログラムのメッセージ監視レベルは二種類あります。一つはプロシージャーレベルと呼ばれるもので、CLプログラム内の一番最初の演算命令よりも前に記述されているMONMSGコマンドを指します。このMONSMGコマンドはこのCLプログラム（USRLIB/CLPGM1）のどのステートメント実行時かに関わりなく指定したMSGIDを監視できます。一方、特定の演算命令の直下に置かれるMONMSGコマンドはコマンドレベルのメッセージ監視と呼ばれ、直前の演算命令の処理結果についてだけメッセージ監視を行います。もしプロシージャーレベルとコマンドレベルで同じメッセージIDを監視した場合、コマンドレベルの指定の処理が優先されます。
MONMSGコマンドで監視できるメッセージタイプ
IBM i OSのメッセージにはタイプという属性があります。図2の例CPI1E94ではメッセージタイプは 情報 = *INFO となっています。（DSPMSGD RANGE(CPI1E94)というようにメッセージIDが分かればDSPMSGDコマンドで確認できます）
▲図2. コマンド画面
メッセージのタイプは表1のように合計10種類ありますが、MONSMGコマンドで監視可能なのは通知メッセージ（*NOTIFY）、状況メッセージ(*STATUS)、エスケープメッセージ（*ESCAPE）の3種類だけです。これ以外のメッセージIDを指定してもMONMSGコマンドでは監視できないので注意してください。
▼表1. メッセージのタイプ
| メッセージの種類 | 説明 | MONMSGコマンドで監視可能 |
|---|---|---|
| *INFO（機能） | 機能の条件に関する情報のメッセージ | 不可 |
| *INQ（照会） | 何らかの応答を要求するメッセージ | 不可 |
| *NOTIFY（通知） | プロシージャーまたはプログラムからの応答を要求するメッセージ | 監視可能 |
| *RPY（応答） | 受信した照会又は通知メッセージに対する応答メッセージ | 不可 |
| *COPY（送信元のコピー） | 送信元によって保管される *INQ照会または*NOTIFY通知メッセージのコピー |
不可 |
| *RQS（要求） | 受信プロシージャーまたはプログラムの機能を要求するメッセージ | 不可 |
| *COMP（完了） | 作業の完了を伝えるメッセージ | 不可 |
| *DIAG（診断） | システム機能、アプリケーション、入力データに関するエラーのメッセージ | 不可 |
| *STATUS（状況） | プロシージャーまたはプログラムの処理状況を通知するメッセージ | 監視可能 |
| *ESCAPE（エスケープ） | プロシージャーまたはプログラムが異常終了する条件を記述したメッセージ | 監視可能 |
たとえばワーク用のテーブル（PF）を作成する場合、同名のファイルを作成しようとするとエラーが発生し、この際、図3のように2つのメッセージが記録されますが、MONMSGコマンドで監視できるのはエスケープメッセージの CPF7302だけです。このような仕様は機能を制約するものではなく、診断レベルのメッセージIDは多数存在しますが最終的にテーブルが作成されなかったという1つのエスケープメッセージに集約されるので、監視対象をシンプル化・標準化できるというメリットがあります。
▲図3. MONMSGコマンドで監視できるのはタイプ *ESCAPE、*STATUS、*NOTIFY の3種類
MONMSGコマンドでのメッセージ番号の指定の仕方
またMONMSGコマンドでは色々な指定の方法が可能です。以下にいくつかの例をご紹介します。IBM i のメッセージ体系では先頭の３文字（MCH, CPF, SQL, RPG,など）が出力元のプログラムの種類・カテゴリーを示しています。ちなみにMCH＝マシン＝マイクロコード層、CPF＝OS層=S/38のOS CPF(Control Program Facility)、の意味です。※下記のメッセージIDは例であり実ケースに基づいたものではありません。
- MONMSG MSGID(CPF7302)
CPF7302 だけを監視する - MONMSG MSGID(CPF7302 CPF5101 MCH1211)
複数のメッセージIDを監視する - MONMSG MSGID(CPF7300)
CPF73xx (xxは01～99)の全てのメッセージを監視する ※00はワイルドカードとして機能 - MONMSG MSGID(CPF0000)
CPFではじまるすべての監視可能なメッセージを監視する ※0000はワイルドカードとして機能
また、上記の図1では監視エラー発生時にメッセージを送信していますが、EXECパラメーターには別なCLプログラムを起動したり、以下のような処理を行わせたりすることも可能です。
- MONMSG MSGID(CPF7300) EXEC(CALL USRLIB/CLPGM2)
同じCLプログラム上の別なステートメントに分岐させたりする - MONMSG MSGID(CPF7300) EXEC(GOTO ERROR)
※CLP CLPGM1のERROR ラベルに分岐する
（参考）IBM i のジョブタイプ
IBM i上で実行されるジョブの種類は以下のように分類されます。今回の例はユーザープログラムによるメッセージ取得ですが、これ以外のどのようなジョブタイプでもメッセージ待ち行列へのメッセージ送出が可能です。
| ジョブタイプ | 説明 | 例 |
|---|---|---|
| 対話式ジョブ | 5250端末から実行されるジョブ | 5250端末からサインオンした際、INLPGMで実行されるCLP他プログラム、5250端末ジョブから起動されるジョブ |
| バッチジョブ | SBMJOBコマンドで投入されたジョブなど | ユーザー・オペレーターの応答を待たずに処理が実行される一連のプログラム。一般的には自バッチジョブは実行優先度が低く設定される。ユーザーが開始するバッチジョブは通常QBATCHサブシステム配下で実行される事が多い。 |
| 通信ジョブ | IBM i の外部からのプログラム開始要求に従って開始されるバッチジョブ | ODBC/JDBC等の接続要求、TELNET,SSH,HTTP(S),FTP等のTCP/IP通信プログラム、APPC通信、DRDA(分散DB処理)接続要求など |
| サーバージョブ | IBM i システム上のバックグラウンドで継続的に実行されるジョブ | TELNET,SSH,FTP等TCP/IP通信サーバープログラム（UNIX,Linux等のデーモンに相当）。IBM i Accessのホストサーバージョブ、 |
| 自動開始ジョブ | サブシステムSBSD起動時に実行が指定されている一連のジョブなど | WRKSBSDコマンドのオプション3自動開始ジョブ項目で指定されているプログラム、など |
| 事前開始ジョブ | ユーザーや他のアプリケーションプログラムからの実行要求を受け取る前にメモリ上に展開されて実行を待っているジョブ | WRKSBSDコマンドのオプション10事前開始ジョブ項目で指定されているプログラム。ODBC/JDBCを処理するQZDASOINIT事前開始ジョブなど。事前開始ジョブ項目で指定してサーバージョブやバッチジョブを開始する事もできる。事前開始ジョブはたとえばODBC/JDBC接続のよう開始に要求があったタイミングでサーバージョブを起動するとパフォーマンスが劣化してしまう場合などで、サブシステム起動直後にODBC/JDBC接続用ジョブを開始しておき開始要求があった際即時に応答出来るようにするような目的で使用される。 |
| リーダージョブ（読取りプログラム）とライタージョブ（書き出しプログラム） | リーダー・ジョブ はスプール入力ジョブであり、ライター・ジョブはスプール出力用ジョブ | リーダージョブはWRKRDRコマンドで表示される。ライタージョブはWRKWTRコマンドで表示される印刷出力用のジョブ |
| システムジョブ | IBM i OS起動時やIASPがオン変更時開始されるジョブ | IBM i OS起動時に開始される以下のジョブ。SCPFシステムジョブによって開始されるQSYSARB,QSYSARB2システム・アービター・ージョブ、システム通信ジョブ、データベースジョブ、その他システムジョブ（Qhst, Qjobscd, Qfilesys1, Qdcpobjx, Qatert,など） |
参考URL:IBM i のジョブ・タイプ
https://www.ibm.com/docs/ja/i/7.5?topic=jobs-job-types
今回のCLPサンプルプログラムと結果例
※プログラムを実行する前にCRTMSGQ USRLIB/USRMSGQ1 コマンドでメッセージキューを作成します。
その後、上記プログラムをサインオンして2回以上実行するとエラーが発生します。その際、メッセージキューUSRLIB/USRMSGQ1に下記のエラーが出力されます。このサンプルでは簡素化のためにファイル名等を固定情報で出力していますが、CLP上で簡単なプログラミングを追加してファイル名、実行ユーザーID、その他を組み込むこともできます。
参考：Navigator for i のシステムモニターからメッセージを送信する
以下の記事にNavigator for i（ブラウザーGUI画面）からシステム資源（CPU, メモリ, ディスク, N/Wアダプター等）の稼働率を監視しユーザー設定の閾値を超えた際にQSYSOPR等のメッセージキューに通知する方法をご紹介しています。
【できるIBM i 7.4解剖】 第13回「IBM i 7.4操作・運用あれこれ」
https://www.i-cafe.info/column/serials/dekiruibmi_no13
