バッチ処理の思い出
私は、
- （白いキャニスターに入った、ロングの）MT媒体（入力1本か2本、出力1本）
を（ジョブステップ毎に）使った、バッチ処理（のお手伝い）をした事が有ります。
ただし、ソートのワーク領域は既に、DASD（後述）になっていました。
入力MTは、決してその日には上書きせず、残す規則になっていました。
複数のジョブステップでは、
- 前の出力MTが次の入力MTになるのは常套でしたが、
- 全て残す
のです。汎用コンピュータですら故障を考えないといけない過去（30年前）では、当然の措置だったと思います。
故障が減り、冗長化も可能になってから、リアルタイムオンライン処理という仕組みが可能になったと思います。
バッチ処理の悪い思い出
その後、入力、出力とも、DASD（MT媒体をハードディスクで模倣するファイルシステム）になった夜間バッチ処理で、
- エラーが起きていて、
- それを理解していたのにもかかわらず、
- 処理を進めてしまった
事で、上司にまじで鬼づめされた事が有りました。
バッチ処理のましな思い出
なぜ、鬼づめだけで済んだのでしょうか？
それは、
- 全ての入力MTを残しており
- 再実行が完全に可能だった
からです。
バッチ処理は、誰が高説を垂れることも関係無く、良い性質が有るのは事実です。
制御の反転（Wikipedia 日本語版）といった、良い性質も、バッチ処理相当の処理の範囲内で可能だと思います。
1980年代終わりの頃の話です。
結論
リアルタイムオンライン処理で有る事が明記されたシステム開発で、バッチ処理に回帰させる事をだましてしたら、契約不適合責任に問われ、損害賠償の請求が可能になると思います。
また、偽計業務妨害の告訴状をなんとか受け取ってもらう様、努力をするのも有りだと思います。
これからも「商用技術者の価値」を蔑ろにする事でプログラミングが嫌いになる人は存在し続けることでしょう。
