Exercise 3: Why REWRITE Needs I-O Mode and a Prior Successful READ — Possible Solution ==================================================================== WHAT REWRITE GENUINELY DOES, PER THIS CHAPTER This chapter's own finding-box states REWRITE's real purpose plainly: it replaces an existing real record in place - it is not a way to add a brand-new record the way WRITE is. The whole real operation only makes sense against a record that genuinely already exists in the file. WHY OUTPUT MODE GENUINELY CAN'T SUPPORT THAT OPERATION Fundamentals' own Chapter 8 material, referenced directly in this chapter, establishes that OUTPUT mode's real purpose is writing only, typically for creating a file or replacing its entire content from empty. A file opened OUTPUT is being treated as a genuinely fresh target for new records, not as an existing body of data with individual records available to be located and updated. REWRITE needs the file to already hold real, existing records it can locate and replace - a requirement OUTPUT mode's own real behavior doesn't support. I-O mode, by contrast, genuinely permits both real reading and real writing against the same already-open file, which is exactly what locating an existing record and then replacing it requires. WHY REWRITE GENUINELY DEPENDS ON A PRIOR SUCCESSFUL READ This chapter's own worked example shows the real sequence explicitly: READ CUSTOMER-FILE first, using CUST-ID to locate the real record, and only afterward - once that real record's own current content is sitting in CUSTOMER-RECORD's storage - does ADD 500.00 TO CUST-BALANCE modify it, followed by REWRITE CUSTOMER-RECORD to save that modified version back. REWRITE itself doesn't perform its own lookup; it operates on whatever record currently occupies CUSTOMER-RECORD's storage, at whatever position the file was last positioned to. WHY SKIPPING THE READ WOULD GENUINELY FAIL If REWRITE were attempted without first successfully reading the target record, there would be no real guarantee that CUSTOMER-RECORD actually holds that record's genuine current content, and the file itself wouldn't be correctly positioned at the real record being targeted. This chapter's own material notes REWRITE's own INVALID KEY condition exists specifically to report cases like this - attempting to replace a record that the file position or key value doesn't actually correspond to a real, existing record. ANSWER: REWRITE requires I-O mode because it operates on a real record that already exists in the file, and OUTPUT mode's own purpose is writing fresh content rather than locating and updating existing records - only I-O mode genuinely permits both reading and writing together, which REWRITE needs. It requires a prior successful READ of the same record because REWRITE doesn't perform its own lookup; it replaces whatever content is currently sitting in the record's own storage area, at whatever position the file was last positioned to by that READ. Attempting a REWRITE without that prior READ would leave no real guarantee the record's storage holds accurate current content or that the file is correctly positioned at the intended record, exactly the kind of situation REWRITE's own INVALID KEY condition is there to catch. WHY THIS WORKS AS AN ANSWER ------------------------------ This correctly connects REWRITE's I-O requirement back to the real OUTPUT/I-O distinction from Fundamentals, and explains the prior-READ dependency through REWRITE's own actual mechanism (replacing existing storage content, not performing an independent lookup) rather than treating it as an arbitrary sequencing rule.