Recursive CALL Procedures in MS-DOS 6.22 Batch Files

This article examines how the MS-DOS 6.22 command interpreter, COMMAND.COM, handles iterative batch processing through recursive CALL procedures. It covers internal state preservation, memory overhead, execution flow, and the operational limitations that distinguish recursive batch loops from standard iterative constructs like GOTO.

In MS-DOS 6.22, executing a recursive loop involves a batch file invoking itself using the CALL command, typically paired with conditional logic like an IF statement to establish a base case. Unlike a GOTO label jump, which simply moves the internal file pointer to a different location within the already open script, CALL forces COMMAND.COM to treat the invocation as a nested subroutine.

When CALL executes, COMMAND.COM creates a new nested execution context. It preserves the state of the calling batch file—including the file name, the current line number, and the exact byte-offset position within the file—onto an internal DOS stack maintained in conventional memory. Control is then passed to the target batch file, which, in a recursive loop, is the script itself.

COMMAND.COM does not load entire batch scripts into memory at once. Instead, it reads and parses batch files line by line directly from the storage device. During recursive CALL loops, each invocation triggers a distinct file read operation starting from the beginning of the file. COMMAND.COM must re-parse the arguments passed to the script on each recursive entry, re-populating the positional parameter variables (%0 through %9).

The recursive unwinding phase occurs when the terminal condition is reached and the script reaches the end of the file (or an explicit EXIT in third-party shells, though MS-DOS 6.22 simply falls off the end of the script). COMMAND.COM retrieves the previous state from its internal stack, re-opens the batch file (if the file handle was closed), seeks to the saved byte offset, and resumes execution immediately after the CALL line that initiated the recursion.

Because COMMAND.COM retains execution state in conventional memory, recursion depth in MS-DOS 6.22 is limited. Each nested CALL consumes a portion of COMMAND.COM’s internal stack and batch context memory. If a recursive loop does not terminate in time, the system will encounter an "Out of environment space" error, an internal stack overflow, or freeze entirely due to memory exhaustion. Consequently, while recursive CALL loops provide functional recursion, standard loops utilizing GOTO and labels are substantially faster and consume minimal memory in MS-DOS 6.22.