Batch Window Arithmetic Before and After Growth
An insurance batch cycle must finish inside a 240-minute window that opens at 01:00 on a shared partition. The main job processes 3.9 million policy records. Measured costs per 1,000 records are 0.5 seconds for validation, 1.4 seconds for sorting, and 0.3 seconds for output formatting. Fixed costs per run are 12 minutes for sort initialization and 7 minutes for control reports. A 25-minute incremental backup runs after the main job and consumes part of the same window. Next year's volume is forecast to grow 15 percent, and a new audit file must be written from the sorted data, at an additional 0.4 seconds per 1,000 records, attached to the formatting step. Operations standards require 30 minutes of contingency to remain inside the window before a job is accepted for production.
1. Compute the current elapsed time and the remaining contingency. Does the run meet the standard today?
Read the worked answer
Per 1,000 records today: 0.5 + 1.4 + 0.3 = 2.2 seconds. For 3.9 million records that is 3,900 units of 1,000.
3,900 x 2.2 = 8,580 seconds = 143.0 minutes.
Add fixed costs: 143.0 + 12 + 7 = 162.0 minutes for the main job. Add the backup: 162.0 + 25 = 187.0 minutes.
Contingency: 240 - 187.0 = 53.0 minutes, or about 22 percent of the window.
Yes, the run meets the 30-minute standard today, with 53 minutes to spare. Note what the 53 minutes absorbs: a single re-run of the main job is impossible inside this window, since 162 minutes cannot fit in 53. The run meets the standard but has no capacity for a full restart, which matters if the job is restartable only from the beginning.
2. With 15 percent growth and the audit file added, does the run still meet the standard? Find the largest record count that would.
Read the worked answer
New volume: 3.9 million x 1.15 = 4.485 million records, or 4,485 units of 1,000.
New per-unit cost: 2.2 + 0.4 = 2.6 seconds.
4,485 x 2.6 = 11,661 seconds = 194.35 minutes. Add 12 + 7 + 25 = 44 minutes fixed and backup: 238.35 minutes. Contingency is 240 - 238.35 = 1.65 minutes.
That fails the 30-minute standard badly. It also sits inside any reasonable estimate error: a 1 percent miss on the per-record cost alone adds nearly 2 minutes and pushes the run past the window.
Largest record count meeting the standard: 240 - 44 - 30 = 166 minutes available for record processing. 166 x 60 = 9,960 seconds. 9,960 / 2.6 = 3,830.8 units of 1,000, so about 3,830,000 records.
That ceiling is below today's 3.9 million. Even at current volume, adding the audit file breaks the standard, so the growth forecast is not the only problem to solve.
3. Recommend one change, quantify its effect, and state the condition under which it is acceptable.
Read the worked answer
Move audit file generation out of the window and run it after 05:00 from the sorted data set, provided that sorted data set is retained.
Effect: the audit write costs 0.4 seconds per 1,000 records. At 4.485 million records that is 4,485 x 0.4 = 1,794 seconds = 29.9 minutes removed from the in-window elapsed time. New elapsed time is 238.35 - 29.9 = 208.45 minutes, leaving 31.55 minutes of contingency, which clears the 30-minute standard by a narrow margin.
Conditions for acceptability:
- The audit file must not be an input to anything that runs before 05:00; otherwise this simply moves the delay downstream.
- The sorted intermediate must persist long enough and be protected from the next night's run overwriting it.
- A failed audit job must raise an exception, not fail silently, because nothing in the batch window is checking it any more.
The 1.55-minute margin above the standard is thin, so pair this with a measured re-baseline of the per-record costs before committing to next year's schedule.