AS400のCLとは｜CALL・SBMJOB・MONMSG・CPF0000の読み方

2026.05.22

CL保守でよく確認するCALL、SBMJOB、MONMSG、CPF0000を中心に、ジョブログとライブラリリストを見ながら処理の流れを確認する手順を整理しています。

AS400 / IBM i のCLは、コマンドを順番に実行して、RPGプログラムの呼び出し、バッチ投入、ファイルの一時的な切り替え、エラー時の処理を制御するための言語です。CLだけで業務処理のすべてを書くというより、RPGやコマンドをつなぐ「運用と制御の入口」として使われることが多いです。

この記事では、CL保守でよく出るCALL、SBMJOB、MONMSG、OVRDBF、DLTOVR、ライブラリリスト、ジョブログ確認を、初心者でも実務で追える順番で整理します。

AS400のCLソースを表示した画面
掲載ソースの画像にはADDLIB、RMDLIB、PGM200などの表記があります。標準CLのADDLIBLE・RMVLIBLE・PGMと同じ構文として写さず、使用ツールや独自コマンドの定義、変換後のCLを確認してください。画像は外部ライブラリ参照の流れを読む例であり、そのまま実行できる標準CLのサンプルではありません。

CLで見る全体像

見る場所意味保守で見るポイント
PGM / ENDPGMCLプログラムの開始と終了PARMで受け取る値があるか確認する
DCL変数定義型、桁数、初期値を確認する
CHGVAR変数への代入日付、ゼロ埋め、文字連結を確認する
IF / DO / ENDDO条件分岐どの条件で後続処理へ進むかを見る
CALL別プログラムを呼び出すRPG側の更新やパラメータを確認する
SBMJOB別ジョブとして投入する投入後すぐ戻るため、完了確認が別途必要
MONMSGメッセージ発生時の処理エラーを握りつぶしていないか見る
OVRDBF / DLTOVRファイル参照先の一時変更と解除解除漏れ、対象ファイル違いに注意する

CALLとSBMJOBの違い

CALL は、その場で別プログラムを呼び出して、基本的には処理が戻るまで待ちます。画面処理や前後関係が重要な処理でよく使われます。一方、SBMJOB はジョブキューへ投入し、バッチジョブとして別に実行させます。CL側は投入した時点で次へ進むため、後続処理が「バッチ完了後」を前提にしていないか確認が必要です。

PGM PARM(&ORDNO)
DCL VAR(&ORDNO) TYPE(*CHAR) LEN(10)

CALL PGM(ORDERLIB/ORDRPG) PARM(&ORDNO)

ENDPGM
SBMJOB CMD(CALL PGM(TESTLIB/BATCHPGM)) +
       JOB(TESTBATCH) JOBQ(TESTLIB/TESTJOBQ)

2つ目は、引数を取らない検証用プログラムを投入する別の構文例です。1つ目のORDRPGからPARMを省略してよいという意味ではありません。名前は架空です。ジョブ投入は実行操作なので、閲覧のために実行せず、検証環境・対象プログラム・JOBQを確認してから使います。

MONMSGの読み方

MONMSG は、CLで発生したメッセージを監視して、エラー時の処理を指定する命令です。保守で特に注意したいのは、CPF0000 のような広い指定で何でも拾い、そのまま処理を続けてしまう書き方です。エラーを通知して止めるのか、代替処理へ進めるのか、ログだけ残してよいのかを確認します。

PGM
CHKOBJ OBJ(TESTLIB/INPUTPF) OBJTYPE(*FILE)
MONMSG MSGID(CPF9801) EXEC(DO)
   SNDPGMMSG MSGID(CPF9898) MSGF(QCPFMSG) +
     MSGDTA('Required file was not found. Check the job log.') +
     MSGTYPE(*ESCAPE)
ENDDO
ENDPGM

上は、検証用の架空ファイル名を使い、存在確認のCPF9801を呼出し側へのエスケープ通知へ置き換える構文例です。対象ファイルのデータは消しません。CHKOBJはファイルの確保や、後続処理の成功まで保証するものではありません。実行前に検証環境でコンパイルし、呼出し側の異常処理まで確認してください。IBM公式のエスケープ通知例も参照できます。

MONMSGは置く位置で、直前のコマンドを監視する場合とプロシージャー全体を監視する場合が変わります。上の例は直前のCHKOBJに対する指定です。CPF0000で広く捕捉して通常RETURNするだけでは、呼出し側が異常を見落とすことがあります。実際に処理するメッセージと通知方法を決めてください。

OVRDBFとDLTOVR

OVRDBF は、プログラムが参照するファイルを一時的に別のファイルやメンバーへ切り替える時に使われます。テスト用ファイル、ワークファイル、特定メンバーの指定などで使われます。便利ですが、どの範囲に効いているかを誤ると、本番データを見ているつもりで別ファイルを見ていた、という事故につながります。

CL内では、OVRDBFによる指定、対象プログラムの呼び出し、DLTOVRまたはスコープ終了による解除の順を追います。上書きの範囲はOVRSCOPEで異なり、途中の異常時にも後続処理へ残らないかを確認します。具体的な範囲の見方はOVRDBFの確認手順を参照してください。

DLTOVR はオーバーライドの解除です。CLの途中でエラーになった時も解除される設計になっているか、同じジョブ内の後続処理に影響しないかを確認します。

ライブラリリストを確認する

CLでは、プログラム名やファイル名をライブラリ省略で書くことがあります。その場合、実際にどのオブジェクトが使われるかはライブラリリストに依存します。本番、検証、開発で同じCLを動かしても、ライブラリリストが違えば参照先が変わります。

コマンド見ること注意点
DSPLIBL現在のライブラリリスト本番/検証/開発の順序差を見る
ADDLIBLEライブラリ追加同名オブジェクトの解決順序が変わる
CHGLIBLライブラリリスト変更後続処理全体へ影響する
CALL PGM(LIB/PGM)明示ライブラリ指定環境固定になっていないか確認する
CALL PGM(PGM)*LIBL参照実行時のライブラリリスト確認が必須

CL保守で危ない見落とし

  • SBMJOBで投入しただけで、完了したと思ってしまう
  • MONMSG CPF0000でエラーを広く拾い、異常を見逃す
  • OVRDBFの解除漏れで、後続処理の参照先が変わる
  • *LIBL参照なのに、実行時のライブラリリストを確認していない
  • CALL先のRPGで実際の更新が行われている
  • 本番固有のライブラリ名やジョブキュー名を検証環境でそのまま使う

ジョブログで確認すること

CLの障害調査では、CLソースとジョブログを必ずセットで見ます。どのコマンドで止まったのか、MONMSGで拾われたのか、CALL先のRPGでエラーになったのか、SBMJOBで投入された別ジョブ側で失敗しているのかを分けます。ジョブログの基本は AS400のジョブログ確認手順 も参考にしてください。

まとめ

AS400 / IBM i のCL保守では、CALL、SBMJOB、MONMSG、OVRDBF、DLTOVR、ライブラリリストを中心に見ると、処理の流れを追いやすくなります。CLは業務ロジックそのものというより、RPGやコマンドを動かす制御役です。だからこそ、呼び出し先、投入先、エラー時の分岐、実行環境をセットで確認することが重要です。

CLから呼ばれるRPG側の読み方は AS400のRPG保守ポイント、ライブラリやオブジェクトの基本は AS400のライブラリとオブジェクト もあわせて確認すると、保守調査のつながりが見えやすくなります。

スポンサーリンク