IE50140J
IE50140J

以下のJCLに注意点については、特にほかのJCLも含めて周知をお願いします¶

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

IE50140J　COND による制御フローと注意喚起¶

• ステップ番号 #1〜#13 は詳細設計書・ジョブフロー図に合わせる。略称は詳細設計書 3章の定義に従う。
• これまで解析した JOB（BY60410J、BU82905J、BU83000J、TXR0092J、DAIBAT2J）は JOB 文の COND=(9,LT) だけで制御していた。ステップ単位で直前ステップの RC を見る COND 指定があるのは本JOB だけである。

1. COND 指定の一覧と読み方¶

• COND は「条件が真のとき実行しない（バイパスする）」という指定である。(6,LT,IE50135P) は「6 が IE50135P の RC より小さい（LT）なら飛ばす」と読む。
• ステップに COND がある場合も、JOB 文の COND は合わせて判定される。JOB 文の条件（RC≥10）が成立していれば、ステップの COND に関係なく実行しない。
• どこかのステップが異常終了（ABEND）した場合、COND=EVEN／ONLY の指定が無いため、以降の全ステップは実行しない。

2. 制御フロー¶

2.1 全体¶

#1 IE50135P（配信データM 更新）
   ├ RC 0〜6  → #2 ALTDUMMY 実行（BASEMN をクリア） → #3 へ
   ├ RC 7〜9  → #2 をバイパス（BASEMN は残る）      → #3 へ（JOB は続行）
   └ RC ≥10／ABEND → #2〜#13 をすべて実行しない（JOB 終了）

#3 IE50105P（配信データ管理M 更新）
   ├ RC 0〜6  → #4 ALTDUMMY 実行（INDXL0 をクリア） → #5 へ
   ├ RC 7〜9  → #4 をバイパス（INDXL0 は残る）      → #5 へ
   └ RC ≥10／ABEND → #4〜#13 を実行しない

#5 IE50055P（配信荷主M 更新）
   ├ RC 0〜6  → #6 ALTDUMMY 実行（HCGMNT をクリア） → #7 へ
   ├ RC 7〜9  → #6 をバイパス（HCGMNT は残る）      → #7 へ
   └ RC ≥10／ABEND → #6〜#13 を実行しない

#7 IE50170P（メール配信顧客M 更新）
   ├ RC 0〜9  → #8 へ（ステップ COND なし）
   └ RC ≥10／ABEND → #8〜#13 を実行しない（NIMALD は残る）

#8 SCRATCH1 → #9 SORTOMIT → #10 IE50171P → #11 IE50172P
   （いずれかが RC ≥10／ABEND なら以降を実行しない）

#12 ALTDUMMY（NIMALD をクリア）
   └ #7〜#11 の RC が 0〜9 なら**必ず実行**（RC 7〜9 でもクリアされる）

#13 SCRATCH2（W0010 の事後削除）

2.2 RC ごとの結果（メンテ入力が残るかどうか）¶

3. 注意喚起¶

注意1　RC 7〜9 は「異常終了」に見えない¶

• RC が 7〜9 のとき、メンテ入力のクリア（#2・#4・#6）だけが飛ばされ、JOB は最後まで続行する。JOB の終了状態は正常に近く見える。
• 一方で、そのメンテ入力は残っているため、次回の実行で同じメンテ入力がもう一度反映される。
• 業務PGM が RC 7〜9 で終わる前にマスターの一部を更新していた場合は、次回に二重更新になるおそれがある（各PGM が同じ入力の再反映に耐えられるかは、プログラムのソースが無いため不明）。
• 運用では、JOB 全体の結果だけでなく、#1・#3・#5 の RC と #2・#4・#6 が実行されたか（FLUSH されたか）をジョブログで確認すること。

注意2　④ メール配信顧客M だけ制御が違う¶

• ①〜③ は「業務PGM が RC 6 以下のときだけクリア」だが、④ の #12 には COND が無い。
• そのため #7 IE50170P・#10 IE50171P・#11 IE50172P が RC 7〜9 で終わっても、NIMALD はクリアされ、再処理できなくなる。
• 意図した違いか（④ は警告レベルでも入力を残す必要がない）、COND の付け忘れかは JCL からは判断できない。業務側に確認が必要。

注意3　途中で止まったときの再実行の起点¶

• JOB は #1 から順にメンテ入力を反映し、正常ならそのつどクリアする。途中で RC≥10／ABEND になったときに #1 から再実行すると、反映済みのマスターにもう一度処理が走る。
  • 例: #10 で異常終了した場合、#7 でメール顧客M は更新済みだが NIMALD は残っている。#1 から流し直すと #7 が同じ NIMALD を再反映する。
• 再実行は、止まったステップ（例: #10）から始めるか、反映済みのメンテ入力を手でクリアしてから流すなど、止まった位置に応じて起点を決めること。
• W0010 は #8 で事前削除するため、#8 以降から再実行すればワークの重複割り当てエラーは起きない。#10・#11 から再実行する場合は、前回の W0010 が残っていることが前提となる。

注意4　メンテ入力を作る側との関係¶

• メンテ入力（BASEMN、INDXL0、HCGMNT、NIMALD）は他システム・オンライン等で作られると推定される。クリアされずに残った入力に、作成元が次の分を追記するのか上書きするのかによって、再反映・取りこぼしの起こり方が変わる。作成元の書き込み方を確認すること。

注意5　ステップ名の重複¶

• ALTDUMMY が4つある（#2・#4・#6・#12）。COND は業務PGM のステップ名（IE50135P 等）を参照しているため、現状の判定には影響しない。
• ただし、ジョブログで「どの ALTDUMMY が FLUSH されたか」を見分けにくく、再実行時に RESTART=ステップ名 で ALTDUMMY を指定すると最初の #2 になる。再実行の指定はステップ順や PROC 名を確認してから行うこと。

4. 移行（Java 化）時の留意事項¶

• COND による「RC 6 以下のときだけクリア」は、業務処理とメンテ入力のクリアを同じトランザクションで行い、業務処理が警告（RC 7〜9 相当）で終わった場合はクリアしない、という形で再現する。
• ④ の #12 については、注意2 の業務確認の結果に合わせて、①〜③ と同じ扱いにするか、現行どおり警告でもクリアするかを決める。
• RC 7〜9 で続行し、RC 10 以上で以降を止めるという2段階の判定は、ジョブ管理（スケジューラ）側の終了コード判定に引き継ぐ必要がある。
• 再実行の起点（注意3）は、ジョブ管理側でステップ単位のリスタートができるようにするか、各処理を同じ入力の再反映に耐えられる（冪等な）作りにすることで対処する。