Reading a Validation Report That Does Not Reconcile
A programmer writes an edit routine for a 5,000-record daily transaction file. The logic is: read a record; if end-of-file, exit; add 1 to READ-CT; if AMOUNT is zero or negative, add 1 to REJ-CT and go to the next read; if the date is outside the current fiscal year, add 1 to REJ-CT and go to the next read; if the key equals PREV-KEY, add 1 to REJ-CT and go to the next read; otherwise set PREV-KEY to the key, add 1 to OK-CT, and write the record. The run report shows READ-CT 5,001, REJ-CT 63, OK-CT 4,937. The analyst's independent count of the input file finds 40 records with zero or negative amounts, 25 with out-of-range dates, 2 records that satisfy both conditions, and 3 records that repeat the key of the immediately preceding record where that preceding record was itself rejected.
1. Reconcile the three reported counters against the independent count. Explain each discrepancy by pointing to the specific line of logic responsible.
Read the worked answer
Expected rejects from the amount and date rules: 40 + 25 - 2 = 63 distinct records, because the 2 records that fail both tests exit at the amount test and are counted once, not twice. That matches the reported REJ-CT of 63.
The 3 duplicate records should also have been rejected, giving an expected REJ-CT of 66 and OK-CT of 4,934. The report shows 4,937 accepted, exactly 3 too many. Cause: PREV-KEY is set only on the accept path. When a record is rejected, PREV-KEY keeps the previous accepted key, so a record that repeats a rejected key never compares equal to it and falls through to the accept path.
READ-CT of 5,001: the read is performed before the end-of-file test, so the final read that returns end-of-file still increments the counter. The file has 5,000 records; the extra count is the terminal read.
Note the trap: 63 + 4,937 = 5,000, so the report is internally consistent. The duplicate defect is invisible unless the totals are compared to an independently derived expected count, which is why self-consistency is not proof of correctness.
2. State the corrected control flow and the counters the report should show.
Read the worked answer
Corrected sequence:
- Read a record.
- If end-of-file, exit without incrementing READ-CT.
- Add 1 to READ-CT.
- If AMOUNT is zero or negative, add 1 to REJ-CT, set PREV-KEY to the current key, and go to the next read.
- If the date is out of range, add 1 to REJ-CT, set PREV-KEY to the current key, and go to the next read.
- If the key equals PREV-KEY, add 1 to REJ-CT, set PREV-KEY to the current key, and go to the next read.
- Otherwise set PREV-KEY, add 1 to OK-CT, and write the record.
The key change is updating PREV-KEY on every path, not only on accept. The duplicate rule is meant to catch consecutive repeats in the input stream, so it must track the last record read, not the last record accepted.
Expected report: READ-CT 5,000; REJ-CT 66; OK-CT 4,934; and the three counters must sum to READ-CT. Add a trailer check that aborts the run if READ-CT does not equal REJ-CT plus OK-CT.
3. Rank the two defects by business risk and justify the ranking.
Read the worked answer
The duplicate defect is far more serious. It silently accepts a transaction that duplicates the key of a rejected record, so the transaction posts to the master instead of being held. In a transaction file, a repeated key usually means a resubmission or a keying error; accepting it double-posts the amount and can pay or bill a customer twice. It also corrupts the audit trail, because the rejected original and the accepted duplicate now tell different stories and nothing in the report surfaces the pair.
The read counter defect is cosmetic. It misstates a control total by one, which is annoying and can trigger false alarms, but it cannot change data. Its only real risk is secondary: it teaches operators that the counters never quite reconcile, so they stop investigating small differences, which is exactly the condition under which the duplicate defect survives.
Both are one-line fixes. Do them in the same change, but if only one can be released tonight, fix the PREV-KEY update and add the trailer check that forces READ-CT to equal the sum of the other counters.