Part three of my June 2025 Paper 2 (9618/22) walk-through, covering three programming-technique staples: text file handling, searching algorithms, and records (composite data types). These are "write the code" skills, so I'll focus on the patterns and the slips that cost marks.
📄 The original paper and mark scheme are on the Cambridge International past papers page. Questions below are paraphrased and all code is my own teaching example, not the official answers.
Text file handling
One question stored time-stamps as fixed-format strings (one per line in a text file) and asked candidates to read the file and total how many entries fell in each hour.
The pattern that solves almost every file question is the read-until-end-of-file loop: open the file, repeatedly read a line while you're not at the end, process each line, then close the file. Here's the shape with my own example — counting how many lines in a log file start with the word ERROR:
DECLARE Line : STRING
DECLARE Count : INTEGER
Count ← 0
OPENFILE "Log.txt" FOR READ
WHILE NOT EOF("Log.txt")
READFILE "Log.txt", Line
IF LEFT(Line, 5) = "ERROR" THEN
Count ← Count + 1
ENDIF
ENDWHILE
CLOSEFILE "Log.txt"
OUTPUT "Errors found: ", CountTwo techniques the examiner is really testing here:
First, extracting part of a string. When data is stored in a fixed format like HHMMSS, you pull fields out with the string functions — LEFT(Line, 2) gives the hour, MID(Line, 3, 2) the minutes, and so on. Knowing LEFT, RIGHT and MID is essential.
Second, the "grouping" technique — counting consecutive matching items. You hold the current group's key (e.g. the hour) and a running count; each time the next line's key matches, you increment; when it changes, you output the previous group and reset. The trap is forgetting to output the final group after the loop ends — that last group never triggers the "key changed" branch, so without a final output line you lose it.
The slips that cost marks: not closing the file, testing EOF in the wrong place (reading one line too many), and forgetting to initialise the counter.
✏️ Practice it: "A text file Scores.txt holds one integer per line. Write pseudocode that reads it and outputs how many scores are 50 or above. State which variable you must initialise and why."Searching algorithms
Another question asked for an efficient search of a sorted array of customer records, returning a result if found and a clear "not found" value otherwise.
The word "efficient" and "sorted" together are a signal. There are two searches you must know, and choosing the right one is part of the mark:
| Linear search | Binary search | |
|---|---|---|
| How it works | Check each element in turn until found | Repeatedly halve the search range, comparing with the middle element |
| Data must be sorted? | No | Yes |
| Speed | Slow — checks up to every element, O(n) | Fast — discards half each step, O(log n) |
| Best for | Small or unsorted data | Large sorted data |
For a sorted list, binary search is the efficient choice. The method: look at the middle element; if it matches, you're done; if your target is smaller, repeat on the left half; if larger, repeat on the right half — until the range is empty. My own example searching a sorted array Nums for Target:
Low ← 1
High ← n
WHILE Low <= High
Mid ← (Low + High) DIV 2
IF Nums[Mid] = Target THEN
RETURN Mid
ELSEIF Nums[Mid] > Target THEN
High ← Mid - 1
ELSE
Low ← Mid + 1
ENDIF
ENDWHILE
RETURN -1 // not foundTwo efficiency points examiners reward: stopping as soon as the item is found (don't keep looping), and handling "not found" cleanly — return a clear sentinel like -1, and if the data has an "unused" marker, stop early when you reach it rather than scanning empty slots.
✏️ Practice it: "Explain why binary search cannot be used on an unsorted array, and state one situation where linear search would still be the better choice even though it's slower."
Records (composite data types)
The final part changed a customer ID from an integer to a string and asked why a single-type array no longer worked, and how to store mixed data instead.
The core rule: an array can hold only one data type. So a 2-D INTEGER array can't suddenly store a STRING ID alongside integer points — the types clash. This is exactly when you reach for a record.
A record (composite data type) groups several fields of different types under one structure. You define the type, then declare an array of it:
TYPE Customer
DECLARE ID : STRING
DECLARE Points : INTEGER
ENDTYPE
DECLARE Members : ARRAY[1:1000] OF CustomerNow each element holds both a string ID and an integer points value — accessed as Members[i].ID and Members[i].Points. That's the clean, mark-scoring answer: define a record type combining the fields, then make a 1-D array of that type.
(Two alternatives worth knowing: parallel arrays — one array of IDs, a matching array of points, kept in step by index — or, less elegantly, concatenating the values into a single string and splitting them later. Records are the preferred solution because they keep related data together.)
✏️ Practice it: "Define a record type to store a book's title (string), year (integer) and whether it's on loan (boolean), then declare an array to hold 200 of them."
Quick recap
- File handling: open → loop while NOT EOF → process line → close; extract fields with
LEFT/MID/RIGHT, and always output the final group after the loop. - Searching: linear search for unsorted/small data; binary search (halving) for large sorted data — stop when found and return a clear "not found" value.
- Records combine fields of different types into one structure; use them (or parallel arrays) when a single-type array can't hold mixed data.
