COBOL: Describe the Record Before the Arithmetic

An invoice record arrives as twelve characters:

ABCD00701250

Somebody knows that the customer identifier is ABCD, the quantity is seven and the unit price is 12.50. The computer doesn’t acquire those facts by admiring the sequence. It needs a description of where each field begins, how long it is and what its contents mean.

Only after that interpretation can the program calculate the line total of 87.50.

This is the territory COBOL was designed to address: records, processing rules and business quantities whose meanings depend on more than the arithmetic signs between them. A decimal point can matter even when no decimal-point character is stored.

The record description is part of the computation.

Specification work before implementations

The initial report dates the Pentagon meeting to May 28–29, 1959, with December distribution, January 1960 acceptance and April publication. It credits committee work and FLOW-MATIC, Commercial Translator and AIMACO influences.¹

The 1959 milestone concerns specification work. It doesn’t establish when every implementation shipped.

The COBOL-60 boundary includes PICTURE’s assumed decimal and ADD’s default rounding, with UNROUNDED requesting truncation.¹

Those details provide the historical anchor for an original record and decimal example. The article doesn’t reproduce an early compiler or claim that all machines stored records in the character encoding used below.

Give the characters boundaries

For our invented invoice format, assign positions as follows:

Field	Stored positions	Chosen pattern	Example
Identifier	1–4	four text characters	ABCD
Quantity	5–7	three decimal digits	007
Unit price	8–12	five digits, last two fractional	01250

These are one-based positions for the reader, not a historical memory map. Together the widths are $4 + 3 + 5 = 12$ characters.

The unit price has three digits before the assumed decimal point and two after. In the report’s PICTURE vocabulary, 999V99 expresses that arrangement: V identifies an assumed point, rather than a stored character.¹

Our display model therefore stores five digits for the price, not six characters including a dot. It interprets 01250 as 1,250 hundredths, giving 12.50.

The same digits could mean 125.0 under another scale, or 1.250 under another. The field’s layout supplies the missing information. Asking whether the stored string contains a decimal point would not answer the question.

Original explanatory SVG, created in 2026. This invented twelve-character display format illustrates field boundaries; it is not a universal historical COBOL encoding.

Our parser takes exactly four characters for the identifier, then three for quantity, then five for price. It rejects a short record rather than guessing which field lost a character.

That policy is original to the teaching model. A real data-processing environment needs its own error behavior, input conventions and recovery procedures. The example isolates the point that a record is a sequence interpreted through an agreed layout.

Decimal interpretation can stay exact

Represent the price as an integer number of cents: 1,250. Multiply by the quantity, seven, to obtain 8,750 cents. Dividing by 100 for display gives 87.50.

This particular calculation doesn’t require rounding. Every quantity is chosen so that the result lies exactly on a cent boundary.

The intermediate units are worth saying aloud. Seven items times 1,250 cents per item gives 8,750 cents. Multiplying seven by the raw string’s apparent number and immediately printing 8750 as whole currency units would preserve the multiplication while ruining the interpretation.

Programs often acquire this kind of error through an otherwise sensible-looking field transfer. The digits arrive intact; the associated scale doesn’t. The result can remain perfectly formatted.

Our checker therefore verifies both the parsed digits and the interpreted amount. It tests that quantity becomes 7, unit price becomes 12.50 and total becomes 87.50. A test of only the final character count would leave the arithmetic meaning unexamined.

Align decimal positions before adding

Now consider a separate invented adjustment example. One amount is 12.345 and another is 74.07. Their exact sum is 86.415.

To inspect the addition, align the decimal positions:

  12.345
+ 74.070
--------
  86.415

The extra zero in 74.070 doesn’t change its value. It makes the shared fractional positions explicit.

If the receiving field retains only hundredths, the exact sum contains more fractional information than the field can store. A policy must decide what happens to the extra part.

Under the positive rounded-cents rule in our example, the discarded thousandths digit is 5, so the hundredths digit increases by one. The result is 86.42.

Under truncation, the excess fractional part is discarded. The result is 86.41.

The COBOL-60 ADD specification’s default rounding and UNROUNDED alternative provide the historical comparison.¹ Our chosen positive amounts avoid making unsupported assertions about every signed rounding case or later revision.

Original explanatory SVG, created in 2026. The positive addition is invented; the explicitly dated COBOL-60 policy differs from assumptions drawn from modern dialects.

The difference is one cent. That doesn’t make it trivial. Repeat a calculation across many records, or compare two programs with different policies, and the totals can diverge while each appears to follow a reasonable rule.

The question is which rule the application requires. The receiving scale states how many places fit; it doesn’t itself establish that rounding and truncation are interchangeable.

Field capacity is another limit

Return to our invoice model and keep the five-digit, two-fractional-place price format. Its largest nonnegative price is 999.99. The three-digit quantity field can hold 999.

Multiply those maxima and the line total is:

$$999 \times 999.99 = 998,990.01.$$

Both inputs fit their own fields. The result doesn’t fit a receiving field that has only three whole-number positions and two fractional positions.

This is a different problem from losing thousandths. There are too many whole-number digits. Rounding to cents won’t make 998,990.01 fit into a capacity of 999.99.

Our teaching serializer explicitly rejects amounts outside its chosen receiving capacity. That rejection is a modern model policy, not a claim about COBOL-60’s exact SIZE ERROR behavior. It prevents a misleading demonstration in which a program quietly drops leading digits and presents a much smaller amount as the completed invoice.

An application must choose and check its overflow behavior. “Numeric field” is insufficient information for that decision.

The general lesson is visible without any dialect-specific exception syntax: designing an output field requires examining the range of results, not merely copying the width of one input.

Records can be well shaped and wrong

Change the invoice quantity from 007 to 070 while leaving every field at its declared width. The total becomes 875.00. The record parser accepts the digit pattern, and the calculation is internally consistent.

It may still be the wrong order.

A record layout can reject alphabetic text in a numeric field, or detect that a field has too few positions. It cannot by itself know whether the customer meant seven items or seventy.

Separate checks are needed for different properties. Our model tests shape, digit interpretation, decimal scale, arithmetic and output capacity. It deliberately doesn’t pretend to validate a customer’s intent or establish a business authorization rule.

Readable field names help a reviewer follow the program’s purpose. They don’t substitute for those checks. A variable named UNIT-PRICE can still contain an amount in the wrong currency or a value imported under the wrong scale.

The clearer the description, the easier it is to ask the right questions. That is a practical benefit, rather than a promise that English-looking source cannot make mistakes.

The two quantity variants also make a small batch test. Process both records and add their line amounts: 87.50 plus 875.00 gives 962.50. Each record must supply its own quantity; accidentally reusing the first quantity for the second line produces 175.00 instead. Resetting or replacing per-record state is therefore part of a batch program’s correctness, even when the same layout applies to every input. Our checker verifies the two-line total separately from the individual field checks.

A portable intention still needs conventions

A record-oriented source description lets a reviewer inspect identifiers, quantities and amounts together. The reader can ask whether a price’s scale agrees with the quantity calculation before following the transfers between individual machine locations.

Physical details don’t thereby disappear. Character representation, numeric storage, file handling and implementation behavior still need suitable contracts. Our twelve-character record is a deliberately narrow display example; it doesn’t assert that an early machine’s decimal numeric field must occupy one modern byte per digit.

That restraint preserves the distinction between logical description and physical representation. The program author can say what the field means, while an implementation realizes it using the supported storage conventions.

The interface between the two is precisely where assumptions need to be checked. A common language helps communicate them, but a common word isn’t proof of an identical encoding or error policy.

The important part precedes the total

I find the record more revealing than the multiplication. Seven times 12.50 is straightforward. Establishing that those are the intended quantity and price requires layout, scale and input interpretation.

The addition example adds a receiving policy. The maximum-range example adds capacity. The seventy-item variant separates valid representation from correct business intent.

COBOL’s early specification gave business data descriptions a central place beside procedures. That arrangement made the record’s interpretation visible as part of the program, rather than leaving every meaning buried in transfers between anonymous locations.

The invoice total can only be right after the digits have become the right quantities.

Footnotes

1. CODASYL, COBOL Initial Specifications, April 1960; foreword/history, ADD V-14–15 and PICTURE VI-30. One original document; examples and validation policy are this article’s teaching work. ↩ ↩² ↩³ ↩⁴