Fortran.CodeCompared.To/COBOL

A Fortran program is a single program name ... end program name block. A COBOL program is split into DIVISIONS: IDENTIFICATION DIVISION names the program with PROGRAM-ID, and PROCEDURE DIVISION holds the executable statements. DISPLAY is COBOL's equivalent of Fortran's print *,, and STOP RUN. is the mandatory final statement of the main procedure.

Fortran comments start with ! and run to the end of the line, exactly like COBOL free-format comments, which start with *>. Both languages inherited comment markers that only exist because of their fixed-column punch-card predecessors, where an asterisk or exclamation point in a specific column marked an entire line as a comment.

Fortran has no mandatory internal structure beyond declarations before executable statements. COBOL mandates up to four DIVISIONS in a fixed order: IDENTIFICATION (program name), ENVIRONMENT (system/file configuration, often empty for simple programs), DATA (all variable declarations), and PROCEDURE (the executable statements). Every COBOL program follows this exact skeleton regardless of size.

Both Fortran and COBOL originally required source code in rigid punch-card columns: Fortran reserved columns 1–5 for labels and column 6 for continuation, while COBOL reserved columns 1–6 for sequence numbers, column 7 for a comment/continuation indicator, and split code into an "Area A" (columns 8–11) and "Area B" (columns 12–72). Modern compilers accept free-format source instead — Fortran since the 1990 standard, COBOL via the >>SOURCE FORMAT IS FREE directive shown at the top of every COBOL example on this page.

Fortran only enforces explicit variable declarations when implicit none is present — without it, an undeclared variable silently gets a type from its first letter (a notorious historical bug source). COBOL has no equivalent implicit-typing danger: every data item must be declared in the DATA DIVISION with an explicit PICTURE clause before it can be used, so COBOL enforces what Fortran only enforces by convention.

Fortran's integer is a fixed-width binary type (32 bits by default) with a hardware-defined range. COBOL's PIC 9(5) instead declares a decimal field with exactly 5 digits — its range is determined by digit count, not by bits, and it is unsigned unless declared with an S prefix. A COBOL integer field with 5 nines can never silently wrap the way a Fortran integer can overflow past its 32-bit limit; it is a compile-time size constraint, not a binary one.

Fortran's real stores 19.99 as an IEEE 754 binary approximation, which can accumulate tiny rounding error across repeated arithmetic. COBOL's V in PIC 9(5)V99 marks an implied decimal point that is never actually stored as a character — the digits on either side are tracked exactly, with no binary approximation at all. This is the single biggest conceptual gap between the two languages for money-handling code: a Fortran programmer must reach for arbitrary-precision libraries to get what COBOL gives for free.

Both character(len=10) in Fortran and PIC X(10) in COBOL declare a fixed-width, blank-padded text field of exactly 10 bytes — a value shorter than 10 characters is padded with trailing spaces in both languages. Fortran needs trim() to strip the padding before display; COBOL's DISPLAY shows the padding spaces as-is unless the field is explicitly trimmed with a reference modification or intrinsic function.

Fortran has a genuine logical type with literals .true./.false.. COBOL has no boolean type at all — instead, an 88-level condition name attaches a named boolean condition to any field's specific value, so IF ACCOUNT-ACTIVE reads like a boolean test even though WS-STATUS is really an 8-character text field. A Fortran programmer reaching for a COBOL boolean should look for an 88-level, not a data type.

Fortran's KIND system (integer(kind=int64)) controls storage size for performance and range, chosen by the programmer for numerical reasons. COBOL's USAGE clause serves a similar storage-layout role but for a different purpose: the default DISPLAY usage stores one digit per byte as text (for direct compatibility with printed reports and external files), while COMP stores the same value as a packed binary integer for faster arithmetic. Both are storage-format decisions layered on top of a logical value that stays the same either way.

Fortran's parameter attribute creates a true compile-time constant that the compiler rejects any attempt to reassign. COBOL's VALUE clause only sets an initial value — WS-TAX-RATE is an ordinary WORKING-STORAGE field that could be reassigned later with a MOVE, even though this example never does. COBOL has no dedicated named-constant mechanism equivalent to parameter; disciplined naming (and comments) is the only guard against accidental reassignment.

Fortran uses = for assignment, reading left-to-right like most languages. COBOL uses the verb MOVE source TO destination, reading right-to-left in terms of data flow. There is no = operator for assignment anywhere in COBOL's PROCEDURE DIVISION — every assignment is spelled out as an English sentence.

Fortran needs one assignment statement per destination variable. COBOL's MOVE accepts a list of destinations after TO: MOVE source TO dest1 dest2 evaluates the source once and copies it into every listed destination in a single statement — there is no Fortran equivalent of this multi-target assignment.

Fortran variables with no initializer hold undefined garbage until assigned, unless declared with an inline initializer like = 0 (which, as a side effect, gives the variable the SAVE attribute). Every COBOL WORKING-STORAGE field is deterministically initialized when the program starts: to the VALUE clause if present, or to zero (numeric fields) or spaces (alphanumeric fields) if VALUE is absent — COBOL has no concept of an uninitialized field.

A Fortran type declares a reusable named record with fields accessed via %; the type must be declared once and can be instantiated many times. COBOL has no separate named-record declaration — a group item (a level-01 item with subordinate 05-level fields) plays the same structural role, but the layout exists only where it is declared. Field access uses no punctuation at all: WS-FIRST-NAME is referenced directly, with the group/field relationship implied purely by level numbers.

Fortran uses the familiar + and - infix operators. COBOL's traditional arithmetic verbs are English sentences: ADD n TO field and SUBTRACT n FROM field both modify the destination field in place — there is no separate assignment step, and no operator symbols appear at all. COBOL does also support COMPUTE with ordinary operator syntax, covered separately.

For anything beyond simple ADD/SUBTRACT, COBOL's COMPUTE statement accepts a full arithmetic expression with + - * / **, resembling Fortran's ordinary assignment expressions far more closely than ADD/SUBTRACT/MULTIPLY/DIVIDE do. Most COBOL style guides recommend COMPUTE for any expression with more than one operator, reserving ADD/SUBTRACT/MULTIPLY/DIVIDE for single-step English-readable operations.

Fortran's mod() intrinsic computes the remainder as a separate call alongside ordinary / integer division. COBOL's DIVIDE ... BY ... GIVING ... REMAINDER ... computes both the quotient and the remainder in a single statement, storing each in its own named field — there is no separate remainder-only verb.

Adding 0.1 ten times in Fortran's binary real arithmetic can print something like 1.00000012 instead of exactly 1.0, because 0.1 has no exact binary floating-point representation. COBOL's decimal PIC 9V9(4) field represents 0.1 exactly as the digits "0" and "1000", so the same ten additions produce exactly 1.0000 with zero accumulated error. This is why COBOL, not Fortran or any binary-floating-point language, is the standard for financial ledgers.

Fortran's max() and min() intrinsics accept two or more arguments and return the extreme value directly. Standard COBOL has no built-in MIN/MAX verb for arbitrary comparisons (GnuCOBOL's FUNCTION MAX covers tables, not two scalar fields in every dialect), so the idiomatic approach is a plain IF ... ELSE comparison followed by a MOVE — three statements where Fortran needs one expression.

Fortran concatenates strings with the // operator directly in an expression. COBOL's STRING statement is a full sentence: each source is followed by a DELIMITED BY clause (SIZE means "use the whole field"), and the result is written INTO a destination field. There is no infix concatenation operator in COBOL at all.

Fortran's len() returns the declared width of a character variable, and len_trim() returns the length ignoring trailing blanks. COBOL has no distinct "trimmed length" intrinsic pair — FUNCTION LENGTH always returns the declared PICTURE size unless you first pass the value through FUNCTION TRIM, mirroring Fortran's two-step "declared vs. trimmed" distinction with a slightly different mechanism.

Fortran's index() returns the 1-based starting position of a substring, or 0 if not found — directly analogous to a search. COBOL's INSPECT ... TALLYING instead counts how many times a substring occurs, rather than reporting a position. Finding a position in COBOL typically requires reference modification and a PERFORM loop, since INSPECT is built around counting and replacing, not locating.

Fortran has no built-in case-conversion intrinsic in the base language — converting case requires a hand-written loop over character codes with iachar()/achar(), as shown here. COBOL provides FUNCTION UPPER-CASE and FUNCTION LOWER-CASE directly, a rare case where COBOL's standard library is more convenient than Fortran's for a common text operation.

Fortran substring syntax phrase(1:5) gives a start and an end position, both inclusive. COBOL's equivalent, called reference modification, is WS-PHRASE(7:5) — but the second number is a length, not an end position, so it means "5 characters starting at position 7." Porting a Fortran slice to COBOL requires converting the end index into a character count.

Fortran declares an array with a dimension in parentheses directly on the type: integer :: scores(3). COBOL wraps its array (called a table) inside a group item using an OCCURS n TIMES clause on the subordinate field. Both are 1-indexed by default — Fortran and COBOL agree on this, unlike most modern languages.

Fortran iterates a table with an ordinary do loop over an index variable. COBOL has no do loop at all — the equivalent is PERFORM VARYING index FROM start BY step UNTIL condition, a single statement that combines initialization, the step, and the exit test in one sentence, closer in shape to a C-style for loop than to Fortran's do i = 1, 5.

Fortran's sum() intrinsic totals an entire array in one call, operating on the whole array at once. COBOL has no built-in table-sum verb — the standard idiom is a PERFORM VARYING loop that ADDs each element into an accumulator field initialized to zero. What Fortran expresses as a single whole-array operation, COBOL always expresses as an explicit element-by-element loop.

Fortran declares a 2D array directly with two dimensions: matrix(3, 3), and both subscripts appear inside one set of parentheses. COBOL builds the same shape by nesting an OCCURS inside another OCCURS at successive level numbers (05 for rows, 10 for columns) — the two-dimensional structure emerges from the nesting rather than from a single combined declaration, though both languages use the same (row, column) subscript order.

Fortran's allocatable arrays can be sized at runtime with allocate() and freed with deallocate(), so the maximum size need not be known in advance. COBOL's OCCURS n TO m TIMES DEPENDING ON field instead reserves memory for the maximum size m up front at compile time — nothing is dynamically allocated — and a separate counter field tracks how many of those pre-reserved elements are currently considered valid.

Fortran offers a dedicated else if keyword that keeps a multi-branch chain flat. Standard COBOL has no ELSE IF keyword — a chain of conditions is written as nested IF ... ELSE ... END-IF blocks, one level deeper for each additional branch. Every IF needs its own matching END-IF (or a period, in older fixed-format style) to close the scope explicitly.

Fortran's select case/case/case default maps almost one-to-one onto COBOL's EVALUATE/WHEN/WHEN OTHER — both are structured multi-way branches on a single subject value. COBOL's EVALUATE goes further: it can also test multiple independent conditions at once (EVALUATE TRUE with boolean WHEN clauses), a form with no Fortran equivalent.

EVALUATE TRUE is COBOL's idiom for testing a series of unrelated boolean conditions in order, stopping at the first WHEN clause that is true — functionally equivalent to Fortran's if / else if chain, but expressed through the same EVALUATE machinery used for simple value matching. Many COBOL style guides prefer EVALUATE TRUE over nested IFs for exactly this kind of multi-condition chain.

Fortran spells its logical operators with surrounding dots: .and., .or., .not.. COBOL spells the same operators as bare words — AND, OR, NOT — and they combine naturally with 88-level condition names, so IF IS-WEEKDAY AND NOT IS-HOLIDAY reads as an almost literal English sentence built from named conditions rather than raw boolean variables.

Fortran's do i = 1, 5 counts with an explicit loop variable that is visible and usable inside the loop body. COBOL's PERFORM n TIMES only specifies a repetition count — there is no automatic loop variable at all, so this example must maintain its own counter (WS-COUNT) manually with ADD 1 if the iteration number is needed inside the loop.

Fortran's do while (condition) loops while the condition holds — exactly the semantics of a C-style while loop. COBOL inverts the sense: PERFORM UNTIL condition loops until the condition becomes true, so a Fortran do while (balance > 0) becomes a COBOL PERFORM UNTIL balance <= 0 — the same loop, but the boundary condition must be negated when porting.

Fortran's three-part do i = start, stop, step (here counting down by 2) maps directly onto COBOL's PERFORM VARYING index FROM start BY step UNTIL condition — both specify a start value and a step in one line. The difference is the terminating condition: Fortran's stop value is inclusive and the direction is inferred from the sign of the step, while COBOL always requires an explicit UNTIL condition that the programmer must get right for the loop to terminate at the correct point.

Fortran's cycle skips to the next iteration and exit breaks out of the loop entirely — both are dedicated one-word statements. COBOL's EXIT PERFORM breaks out of the innermost in-line PERFORM loop, but there is no dedicated "skip to next iteration" statement — CONTINUE is COBOL's no-op placeholder, used here inside an IF branch to fall through to the next loop pass without executing anything, the closest equivalent to Fortran's cycle.

A Fortran subroutine is a distinct named unit, declared after contains, with its own scope for local variables. A COBOL paragraph is just a label (GREET.) in the PROCEDURE DIVISION followed by statements running to the next label — there is no separate declaration section, no local scope, and no formal parameter list. A paragraph can only read and write the same global WORKING-STORAGE fields as the rest of the program.

This is the biggest structural gap between the two languages' procedural models. A Fortran subroutine declares exactly which arguments it reads (intent(in)), which it produces (intent(out)), and which it does both to (intent(inout)) — the compiler enforces the contract. A standard COBOL paragraph takes no parameters at all: COMPUTE-AREA simply reads and writes WS-RADIUS and WS-AREA because they happen to be global WORKING-STORAGE fields already in scope. Nothing but a comment or a naming convention documents which fields a given paragraph touches.

Calling three Fortran subroutines in sequence requires three separate call statements. COBOL's PERFORM paragraph-1 THRU paragraph-3 executes every paragraph from the first name through the second name, inclusive, in the order they appear in the source file — a single statement that runs a whole contiguous range of paragraphs. This relies entirely on source-code ordering, which makes THRU ranges fragile if paragraphs are reordered or inserted.

A Fortran subroutine receives an array as an explicit argument (data(:)), so it works on whatever array the caller passes in. A COBOL paragraph cannot receive a table as an argument at all — it can only reach the one table already declared in WORKING-STORAGE (WS-MEASUREMENTS). Reusing COMPUTE-MEAN for a different table would mean either duplicating the paragraph or restructuring the data so both tables share the same fields — there is no generic, reusable "function of a table" in traditional COBOL.

Fortran functions and subroutines are recursive only when explicitly marked with the recursive keyword — an important safety default, since a normal Fortran subprogram is not guaranteed to be reentrant. GnuCOBOL requires the analogous PROGRAM-ID. name IS RECURSIVE. clause on the specific subprogram that recurses; without it, a self-call has undefined behavior. This example nests FACTORIAL as a genuine subprogram with its own LINKAGE SECTION rather than a plain paragraph, since ordinary PERFORM of a paragraph cannot recurse in COBOL at all — only a real subprogram CALL can.

A Fortran function returns a value directly through its name (or a result() clause) and is used in expressions like any built-in operator. COBOL has no user-defined function with a true return value used inline in an expression — the closest equivalent is a separate subprogram (here nested inside the same source file and closed with END PROGRAM) that declares its parameters in a LINKAGE SECTION and receives them via PROCEDURE DIVISION USING. The caller invokes it with CALL "name" USING ... and then reads the output parameter afterward as a separate step — a subprogram call can never be embedded inside an expression the way a Fortran function call can. Note that CALL can only invoke a genuine subprogram declared this way, never a plain PROCEDURE DIVISION paragraph label.

Both languages provide the common math operations as intrinsic functions rather than library calls needing an import — Fortran's sqrt(), abs(), mod() and COBOL's FUNCTION SQRT, FUNCTION ABS, FUNCTION MOD are functionally identical. The only syntactic difference is that every COBOL intrinsic must be prefixed with the literal keyword FUNCTION, while Fortran calls its intrinsics exactly like any other function.

Fortran's pure keyword tells the compiler a function has no side effects and does not modify its arguments — the compiler verifies this and rejects violations at compile time, which also permits safe use inside array expressions and parallel constructs. COBOL has no equivalent keyword or compiler check: whether a subprogram avoids side effects is purely a matter of programmer discipline, enforced only by a comment like the one in this example.

A Fortran elemental function is written as if it takes one scalar, but the compiler automatically applies it to every element when called with an array argument — apply_discount(prices) discounts all three prices with no explicit loop. COBOL has no analogous automatic broadcasting; applying an operation to every element of a table always requires an explicit PERFORM VARYING loop written out by hand.

print *, ... in Fortran and DISPLAY ... in COBOL both write to standard output with default formatting, and both accept a comma- or space-separated list of items to print on one line. The main visual difference is that COBOL numeric fields display with their declared digit width (leading zeros for DISPLAY-usage fields are avoided in practice by choosing an appropriately sized PICTURE), while Fortran prints numbers using compiler-default spacing.

Fortran controls output layout with a FORMAT descriptor string passed to write, such as f10.2 for a fixed-width, 2-decimal field. COBOL takes a completely different approach: a second field is declared with a numeric-editing PICTURE clause ($$$,$$$.99) containing literal punctuation, floating dollar signs, and comma insertion characters. MOVEing the raw numeric value into that edited field automatically inserts the commas, decimal point, and leading dollar sign — formatting is a data-movement operation, not a print-time instruction.

Fortran's print *, takes a comma-separated list of items and prints them all on one line with compiler-chosen spacing between them. COBOL's DISPLAY concatenates every operand with no automatic spacing at all — note the literal " " space inserted between WS-NAME and WS-RANK above; omitting it would run the two values together with no gap.

Fortran's "internal file" feature reuses the ordinary write statement with a character variable as the unit, giving an sprintf-like way to build formatted text. COBOL has no internal-file mechanism — the equivalent tool for assembling text from pieces is the same STRING statement used for concatenation, which happily interleaves literals and numeric fields (a numeric field is converted to its DISPLAY-usage digits automatically).

Fortran opens a file directly with open(unit=10, file=..., action="write") and writes to it by unit number — no separate record layout is required. COBOL requires the file to be declared across two DIVISIONS before any PROCEDURE DIVISION statement touches it: SELECT/ASSIGN in the ENVIRONMENT DIVISION names and locates the file, and an FD entry in the DATA DIVISION's FILE SECTION declares the record layout (WS-OUTPUT-RECORD) that every WRITE actually writes. Both examples require a real filesystem and cannot run in the browser sandbox.

Fortran detects end-of-file through the iostat argument on read, which returns a non-zero status once there is nothing left to read — checked explicitly after every read inside a bare do/exit loop. COBOL uses the AT END clause directly on the READ statement combined with an 88-level condition, following the "priming read" pattern: one READ before the loop starts, and one at the bottom of every iteration, so the AT END condition is always checked immediately after each read attempt. Both require a real filesystem.

Fortran identifies an open file by an arbitrary integer unit number chosen by the programmer — write(20, *) and write(21, *) distinguish the two files purely by number. COBOL identifies each file by a programmer-chosen name declared once in SELECT (LOG-FILE, ERROR-FILE) and used by that name everywhere afterward — no arbitrary integers to keep track of, but a separate FD and record layout is required for every distinct file. Both require a real filesystem.

This is one place where Fortran and COBOL genuinely agree, unlike most modern languages: both treat identifiers and reserved words as case-insensitive, so DISPLAY, display, and Display are the same keyword. Convention in both languages is to write reserved words and DIVISION/SECTION headers in uppercase and everything else in a consistent case, purely for human readability — the compiler does not care either way.

Assigning a 9-character string into a 5-character field silently truncates it to "Alexa" in both languages — there is no error, warning, or exception in either Fortran or COBOL. This is a direct consequence of both languages' fixed-width character storage. A Fortran programmer already knows to size character(len=n) fields generously; the same discipline must be applied to every COBOL PIC X(n) field, since COBOL applies exactly the same silent-truncation rule on MOVE.

A Fortran integer silently wraps around on overflow (two's complement, no warning). Without the optional ON SIZE ERROR clause, COBOL arithmetic that overflows a field's declared PICTURE also fails silently, simply truncating the high-order digits — the first ADD 10 TO WS-SMALL-FIELD above (95 + 10 = 105 into a 2-digit field) silently stores 05. Unlike Fortran, COBOL offers an explicit opt-in safety net: adding ON SIZE ERROR to any arithmetic statement lets the program detect and handle the overflow instead of losing digits silently, as the second ADD demonstrates.

Fortran statements are terminated by a newline, with no equivalent of a required trailing punctuation mark. A COBOL period (.) is not decorative — it terminates a sentence and, in older code, can end an entire paragraph. A misplaced or missing period is one of COBOL's most infamous bug sources: a stray period after an IF can silently truncate the scope of that IF, executing statements unconditionally that were meant to be inside the conditional block.

A Fortran programmer freely composes function calls inside an expression, as in square(double_value(base_value)) — the result of one call becomes the argument to the next, with no intermediate variable required. COBOL's CALL statement cannot appear inside an expression at all: it is a standalone statement that writes its answer into a USING parameter of a separately declared subprogram, so composing two operations always requires an explicit intermediate field (WS-DOUBLED here) and two separate CALL statements, never a nested call.

Unlike most languages a Fortran programmer might compare against (C, Python, Ruby, and their 0-based descendants), COBOL tables are 1-indexed by default — exactly like Fortran arrays. This is one of the few places moving between these two languages requires no mental index adjustment at all: the first element of both a Fortran array and a COBOL table is subscript 1, and the last element of a 5-item collection is subscript 5 in both.