A proposal to tune a nightly job has skipped checking when its batch window actually runs. What is the risk?
Select an answer to reveal the explanation.
Short Explanation
Faster in isolation isn't the same as fitting in the window. You need to check the batch window and surrounding schedule before tuning the nightly job.
Full Explanation
The correct answer is that a change that improves throughput in isolation can still miss its batch window or collide with other scheduled jobs if the surrounding schedule was never reviewed. Performance is not just about a single job's speed; a job that runs faster but still finishes after its window closes, or that now overlaps a job it used to run before, causes a scheduling failure regardless of the improvement. The claim that batch windows are fixed by the operating system and cannot be affected by any code change is wrong because scheduling windows are business and operational constraints, not something the operating system enforces on its own. The claim that ignoring the batch window guarantees the job will fail to compile is wrong because window timing has no effect on whether code compiles. The claim that batch window constraints only apply to jobs written in COBOL, not transformed Java, is wrong because scheduling constraints apply to the workload regardless of language. For the exam, check the batch window and surrounding schedule before finalising any change.