A COBOL program that adds packed decimal amounts all night can fail or slow down because of a compile option chosen years earlier. The ARITH compiler option controls the maximum number of digits allowed in decimal arithmetic. Most shops run many programs with ARITH(COMPAT), but some finance, billing, and high-volume calculation programs need ARITH(EXTEND).
What is the COBOL ARITH compiler option?
ARITH tells Enterprise COBOL how much decimal precision the compiler should allow for fixed-point decimal operations. It affects packed decimal, zoned decimal, numeric-edited items, and numeric literals used in arithmetic expressions.
The two common settings are ARITH(COMPAT) and ARITH(EXTEND). The simple rule is this: use COMPAT when 18 decimal digits are enough, and use EXTEND only when the program truly needs decimal results up to 31 digits.
ARITH(COMPAT) vs ARITH(EXTEND)
| Option | Decimal digit support | Typical use |
|---|---|---|
ARITH(COMPAT) |
Up to 18 digits | Standard business calculations where field sizes fit traditional COBOL decimal limits |
ARITH(EXTEND) |
Up to 31 digits | Large packed decimal calculations, high-value balances, interest calculations, and migrated code that defines larger decimal fields |
When ARITH(COMPAT) is enough
ARITH(COMPAT) is usually enough when the program uses ordinary business fields such as account balances, counts, rates, quantities, and totals that stay within 18 digits. It also keeps behavior closer to older COBOL code, which is why many long-running applications still use it.
01 WS-INVOICE-AMOUNT PIC S9(9)V99 COMP-3.
These fields do not need 31-digit arithmetic. Changing the program to ARITH(EXTEND) may not add value unless another expression in the program needs the larger intermediate result.
When ARITH(EXTEND) is needed
ARITH(EXTEND) is useful when a calculation can exceed 18 digits before the final result is stored. That can happen when a program multiplies large quantities by rates, rolls up many account balances, or works with long packed decimal fields from a file or Db2 table.
01 WS-LARGE-BALANCE PIC S9(18)V99 COMP-3.
Even if the receiving field has a normal size, the intermediate arithmetic can need more room. That is the point where ARITH(EXTEND) deserves a closer look.
Performance tradeoff
The older article stated that ARITH(EXTEND) can be slower than ARITH(COMPAT). That is still a useful warning, but it should not be treated as one fixed percentage for every program. The cost depends on how much decimal arithmetic the program performs, how often the code path runs, and what other work dominates the step.
A batch job that spends most of its time waiting on file I/O may not show much difference. A calculation-heavy program that runs millions of decimal operations in a tight loop may show a measurable CPU change. Measure CPU time and elapsed time before and after changing the compile option.
How to review ARITH safely
1. Find large decimal fields
Search the Data Division for packed decimal, zoned decimal, and edited fields with large picture clauses. Pay special attention to fields near 18 digits and fields used in multiplication, division, or compound COMPUTE statements.
2. Check arithmetic expressions
Look for ADD, SUBTRACT, MULTIPLY, DIVIDE, and COMPUTE. The field receiving the answer is only part of the story. Intermediate results can be larger than the final field.
3. Run representative test data
Use test records that contain maximum expected values, not only happy-path values. A program can pass small test data and still fail month-end or year-end processing when balances are higher.
4. Compare CPU and output
Compile the program with the candidate option, run the same input, compare output files, and check CPU time. Keep the compile listing with the change record so the next developer can see why the option was chosen.
Common mistakes
Using EXTEND everywhere
ARITH(EXTEND) should solve a precision need. Do not apply it to every program just because one calculation failed. Start with the program and expression that need more decimal digits.
Ignoring NUMPROC and TRUNC
ARITH is not the only numeric compile option that matters. Numeric sign handling and binary truncation can also affect results. Review related settings such as COBOL NUMPROC compiler option and COBOL TRUNC compiler option when numeric behavior is under review.
Testing only the final field size
A receiving field can look safe while an intermediate result is not. Review the whole expression, especially multiplication and division statements with large decimal operands.
Quick decision checklist
| Question | Recommended action |
|---|---|
| Do all decimal fields and intermediate results stay within 18 digits? | Keep ARITH(COMPAT) unless another project standard says otherwise. |
| Can an expression need 19 to 31 decimal digits? | Test with ARITH(EXTEND) and compare output and CPU time. |
| Is the job calculation-heavy? | Measure CPU before and after the change with production-like input volume. |
| Is the program being migrated to a newer compiler? | Check the compiler migration notes and keep compile options documented. |
Related Mainframe Forum guides
For nearby compiler settings, read COBOL DATA compiler option, COBOL NUMPROC compiler option, and COBOL TRUNC compiler option. For run-time tuning context, see COBOL performance tuning and COBOL data types.
External references
IBM documents the Enterprise COBOL ARITH compiler option, fixed-point arithmetic, and decimal data.
FAQ
What does ARITH do in COBOL?
ARITH controls the maximum number of decimal digits allowed in fixed-point decimal arithmetic during compilation.
What is the difference between ARITH(COMPAT) and ARITH(EXTEND)?
ARITH(COMPAT) supports up to 18 decimal digits. ARITH(EXTEND) supports up to 31 decimal digits for programs that need larger decimal arithmetic.
Does ARITH(EXTEND) make COBOL slower?
It can add CPU cost in decimal-heavy programs because larger intermediate decimal results may be used. The real effect depends on the program, so test with representative input.
Should every COBOL program use ARITH(EXTEND)?
No. Use ARITH(EXTEND) when the program needs more than 18 decimal digits. For ordinary 18-digit business arithmetic, ARITH(COMPAT) is often enough.
