IBM i のジョブスケジュールが開始時間ではなくIPL後に実行された原因は？
Question
当社システムでは、23：00にスケジュールジョブによってジョブが実行されます。
今朝、そのスケジュールジョブのログを確認したところ、23：00ではなく、システムが再起動された時間である06：00頃に実行されていました。
どうしてこのようなことが発生したのかを調査したいのですが、調査方法を教えていただけますでしょうか。
Answer
スケジュールジョブが23：00に開始されなかったということですが、IPL後に実行されていることを考えると、ジョブ自体は、スケジュール通りにジョブ待ち行列（JOBQ）に「投入」されていたものと思います。
ではなぜ「投入」されているにもかかわらず「開始」されなかったのか。
考えられる原因は、23：00に開始されるジョブの前に別のジョブがまだ残っていたから、が一番濃厚でしょう。
ジョブは、まずジョブ待ち行列に投入され、その後サブシステム上で開始されます。
しかし何らかの原因でジョブが開始されない場合は、ジョブ待ち行列上で待ち続けることになります。
ではジョブは常に1つしか開始できないのかというと、それは投入された先であるジョブ待ち行列の設定によって変わります。
そこでまずは、ジョブ待ち行列の設定を確認してみたいと思います。
ジョブ待ち行列の設定は、サブシステムの設定にありますので、ここでは「QBATCH」を例に確認していきましょう。
コマンド「DSPSBSD SBSD(QBATCH)」を実行し、「6.ジョブ待ち行列項目」を選択します。
すると、複数のジョブ待ち行列の設定が表示されるかと思います。
今回投入先と思われるジョブ待ち行列「QBATCH」の設定を見ると、最大活動の値が「1」となっていました。
この場合、前にジョブ待ち行列「QBATCH」に投入されたジョブがシステム上に残っていると、新しいジョブがジョブ待ち行列から解放されない状態になります。
例えばこれが1組限定の高級お寿司屋さんだとすると、前のお客様がいる場合、次のお客様はお店に入れません。
次のお客様がお店に入るためには、前のお客様が食事を終えてお店を出る必要があります。
イメージとしてはそういったところです。
何らかの原因で、前のジョブがシステム上に残り続けていると、次のジョブはジョブ待ち行列で待機しなければなりません。
今回の事象については、DSPLOGなどでログを追いかけた結果、前に投入されたジョブが正常終了されず、メッセージ待ち（MSGW）で止まっていたことが原因でした。
システム再起動によってMSGWになっていたジョブが終了したため、サブシステム開始直後に待機状態だったジョブが開始されたということです。
今回のような事象を解消する方法として、まず前のジョブがMSGWにならないようにするということは前提としてありますが、環境面で対応する場合は、大きく2つの方法が考えられます。
- 最大活動が「1」となっているジョブ待ち行列の設定を変えてしまう
- 別のジョブ待ち行列に投入する
ジョブ待ち行列の設定を変える場合は、コマンド「CHGJOBQE」にて変更可能です。
以下は、最大活動数を10にするコマンドサンプルです。
CHGJOBQE SBSD(QSYS/QBATCH) JOBQ(QGPL/QBATCH) MAXACT(10) 
別のジョブ待ち行列に投入したい場合ですが、スケジュールジョブであれば、登録時に投入先のジョブ待ち行列を指定できますので、そこで変更することが可能です。
デフォルトでは「*JOBD（ジョブ記述）」が指定されています。
使用するジョブ待ち行列は、ユーザープロファイルに指定されているジョブ記述に指定されていますので、そのあたりでも使い分けは可能ですが、今回は説明を省きます。
ジョブがどのような動きをし、どのように影響を及ぼすのか、少しでも把握できていると、今後問題が発生した際の切り分けがスムーズになるかもしれませんね。
by . かんぴょう木綿さん
