Loops in COBOL

PERFORM ... VARYING WS-INDEX FROM 1 BY 1 UNTIL WS-INDEX > WS-LIMIT is COBOL's standard counting loop, initializing the index once, testing the UNTIL condition before each pass by default, and incrementing the index by the BY value after every iteration, which makes it functionally equivalent to a for-loop in languages like C or Java. The index field, often used to subscript a table with WS-ARRAY(WS-INDEX), can be any numeric working-storage field or, in table-handling contexts, an actual INDEXED BY index-name, which the compiler can sometimes optimize more efficiently than an ordinary data item. Because the UNTIL condition is checked before the loop body by default, a loop bound like FROM 1 BY 1 UNTIL WS-INDEX > 10 runs the body for index values 1 through 10 inclusive, a common off-by-one trap for programmers assuming UNTIL means the same as a less-than-or-equal-to condition.

PERFORM VARYING supports an AFTER phrase that lets a single statement drive multiple nested loops without writing them as physically nested PERFORM blocks, for example PERFORM VARYING WS-ROW FROM 1 BY 1 UNTIL WS-ROW > 10 AFTER WS-COL FROM 1 BY 1 UNTIL WS-COL > 10 varies WS-COL completely through its range for every single value of WS-ROW, exactly like a nested for-loop where WS-COL is the inner loop. Multiple AFTER phrases can be chained to control three or more levels of nesting in one statement, which is common when processing multi-dimensional tables such as a matrix or a table of tables. This single-statement form is functionally identical to writing genuinely nested PERFORM ... VARYING blocks, but it keeps the loop control compact and makes the nesting relationship explicit in one place rather than spread across multiple END-PERFORM terminators.

The most common loop pattern in production COBOL is the read-until-end-of-file loop, which reads one record, tests an end-of-file flag typically set by an AT END clause, and repeats until that flag indicates no more data. Because the READ statement must execute before the AT END condition can be known, this pattern is a textbook use case for PERFORM ... WITH TEST AFTER, or equivalently a priming read before a WITH TEST BEFORE loop, both of which guarantee the READ happens before the flag is ever checked, avoiding the classic bug where a WITH TEST BEFORE loop checks an uninitialized end-of-file flag before any record has actually been read. Sequential file processing programs, sorts, and report generators in COBOL almost universally follow this same sentinel-loop shape, making it one of the most important loop patterns to recognize when reading or writing production code.

EXIT PERFORM immediately terminates the innermost enclosing in-line PERFORM loop, transferring control to the statement after END-PERFORM, which is useful for breaking out of a loop early when a condition is discovered partway through the body that the UNTIL clause alone can't express cleanly; EXIT PERFORM CYCLE, by contrast, skips the remainder of the current iteration and jumps straight to the loop's condition test, acting like a continue statement rather than a break. Every conditional loop carries the risk of never terminating if its UNTIL condition depends on a field that the loop body never actually updates, which is a common bug when a programmer forgets to increment an index or set an end-of-file flag inside the loop; because COBOL has no automatic loop-bound safety net, an infinite PERFORM UNTIL will run until the job is manually cancelled or the system resource limits are hit. Defensive COBOL style often adds a secondary safety counter alongside the primary business condition, such as UNTIL WS-EOF = "Y" OR WS-SAFETY-COUNT > 999999, specifically to guarantee termination even if the primary condition logic has a bug.