LCKWはロック待ちを示すジョブ状態です。最初に待っている側と保持している側を分け、対象と業務影響を確認します。オブジェクト単位の確認とレコード単位の確認は同じではありません。
LCKWを見つけたときにすぐ解除しない理由
LCKW を見つけたときは、先に「誰が、どのオブジェクトを、何の処理で保持しているか」を確認します。単純にジョブを終了すると、更新途中のデータ、帳票出力、締め処理、外部連携に影響することがあります。WRKOBJLCK で対象オブジェクトと保持ジョブを確認し、WRKJOB や DSPJOBLOG でそのジョブが正常処理中なのか、MSGW（メッセージ応答待ち）等で処理が進んでいないのかを切り分けます。
- 対象がマスターファイルなら、更新画面や夜間処理が保持していないか確認する
- 対象がスプール、OUTQ（出力待ち行列）、データエリアの場合は、帳票・連携・制御ジョブとの関係を見る
- 保持ジョブがMSGWなら、問い合わせメッセージの内容を確認してから対応する
- 保持ジョブを終了する場合は、業務影響と再実行方法を確認してから判断する
ロック待ちは単独で起きるより、バッチ遅延、MSGW、ジョブログ異常、帳票出力待ちと一緒に見つかることが多いです。関連して MSGWでジョブが止まる時の確認、スプール・OUTQの確認、ジョブログの読み方 も参照してください。
ロック待ちを現場で聞く時のメモ例
ロック待ちは、画面に出ているジョブだけを見ても判断しづらいです。私はまず、利用者が何をしようとしたか、いつから待ち状態になったか、同じ処理を複数人が実行していないかを確認します。そのうえで、WRKOBJLCKやジョブログを見て、止めてよい処理か、締め処理やEDI連携中ではないかを分けます。
| 聞くこと | 理由 |
|---|---|
| 対象画面・対象伝票 | どの業務データがロック対象かを絞る |
| 待ち始めた時刻 | 夜間バッチや大量更新との重なりを見る |
| 再実行した回数 | 同じ処理を重ねてロックを増やしていないか確認する |
ロック待ちは、解除より先に業務影響と原因を分ける
LCKWやロック待ちを見ると、すぐにジョブ終了や解除を考えたくなります。ただし本番では、先に保持しているジョブが正しい処理中なのか、異常停止に近い状態なのか、締め処理や更新処理の途中なのかを分けて確認します。解除だけを急ぐと、二重更新や処理不整合につながることがあります。
| 確認順 | 見るもの | 判断のポイント |
|---|---|---|
| 1 | 業務影響 | どの画面、どの処理、どの利用者が止まっているかを確認する |
| 2 | WRKOBJLCK／DSPRCDLCK | オブジェクト全体のロックはWRKOBJLCK、物理ファイル・メンバー内のレコードロックはDSPRCDLCKで区別して確認する |
| 3 | WRKACTJOB / WRKJOB | CPU、状態、実行時間、ジョブログを見て処理中か滞留かを分ける |
| 4 | ジョブログ | 待ちの前後にエラー、MSGW、コミット関連メッセージがないかを見る |
| 5 | 再発防止 | 処理順、締め時間、画面操作、バッチ競合をメモ化する |
ロック待ちの調査は、若手担当者が判断に迷いやすいテーマです。社内で教える時は、WRKJOBとDSPJOBLOG、WRKACTJOBの確認、ジャーナルとコミットメント制御を合わせて確認すると、単なるコマンド操作ではなく本番判断の流れとして覚えやすくなります。
LCKWで止まった時の一次切り分け表
LCKWは、単に「ロックしているジョブを止めればよい」という話ではありません。保持ジョブ、待ちジョブ、対象オブジェクト、業務影響を分けて確認します。
| 確認点 | 確認内容 | 判断 |
|---|---|---|
| 対象確認 | WRKOBJLCKでファイル名、ライブラリ、ロック状態、保持ジョブを確認する | 同名ファイルが複数ライブラリにないかDSPLIBLも見る |
| 影響確認 | 待っている処理が入力、出荷、請求、締め処理のどれに関係するか確認する | 業務影響が大きい場合は解除判断を運用責任者に上げる |
| 解除判断 | 保持ジョブが画面操作中か、バッチ処理中か、メッセージ応答待ちかを確認する | ENDJOBは最終手段にし、戻し方と再実行可否を先に決める |
ロック待ちは原因探しと同時に、業務を止めてよい範囲を決める対応です。技術担当だけで解除判断を抱え込まないことが重要です。
架空例：同じ受注伝票の更新で待たされる
担当者Aが受注伝票を更新中で、担当者Bも同じ伝票を更新しようとして待った、という架空の例です。Bの画面が固まって見えても、原因を画面不具合やCPU不足と決めず、対象ジョブ、ファイル・メンバー、待ち始めた時刻をそろえます。
WRKOBJLCKはオブジェクト単位のロック確認です。伝票のレコード単位の競合を調べる場合には、物理ファイル・メンバーを特定してDSPRCDLCKの確認へ進みます。IBM公式のDSPRCDLCKの説明では、レコードの保持・待機状態を確認する用途が示されています。
「待ち側ジョブB／保持側ジョブA／対象ファイル・メンバー／確認時刻／Aが行っている業務」を一組で記録します。Aが通常の更新中なら、業務担当に終了予定と待てる期限を確認します。MSGWなら返信内容と途中更新を確認し、放置された操作が疑われても、ジョブ終了や取消は承認された手順で判断します。ロックを見つけたこと自体は、解除してよい根拠にはなりません。
待ちがなくなった後は、Bの処理結果、二重投入の有無、後続の帳票・連携を確認します。画面が返ったことだけで、業務データの整合性まで確認済みとはしません。
遅い原因がロックのこともある
利用者には「遅い」「固まった」と見えていても、裏ではロック待ちになっていることがあります。WRKACTJOBでLCKWが目立つ場合は、待っているジョブだけでなく保持しているジョブを追います。
性能劣化の初動は 遅い時の聞き取り票、本番障害は AS400本番障害の初動チェックリスト、本番反映と戻しは AS400ジャーナル確認手順 を参照してください。
Codexには匿名化して渡す
ロック調査でCodexを使う場合は、ジョブ名やファイル名を匿名化し、状態、発生時刻、確認済み項目だけを渡します。AIには確認順の整理を任せ、ジョブ終了や再実行の判断は人が行います。
