COBOL USAGE Clause: DISPLAY, COMP, COMP-3, and COMP-5

A file copybook may show PIC 9(9), but that does not tell you how the value is stored. A COBOL USAGE clause answers that question. It tells Enterprise COBOL whether the field is stored as display digits, binary, packed decimal, native binary, or floating point.

Pick usage by data purpose.

What is the COBOL USAGE clause?

The USAGE clause specifies the format used to represent a data item in storage. If you do not code it for ordinary numeric or alphanumeric fields, COBOL normally treats the item as DISPLAY. That is easy to read, but it is not always the best choice for arithmetic.

Use USAGE deliberately for fields that appear in calculations, counters, subscripts, DB2 host variables, file records, and interface copybooks. A wrong usage can give bad values, wasted storage, slow arithmetic, or a mismatch with another program.

Quick comparison

Usage	Meaning	Common use
DISPLAY	External decimal or character representation.	Report fields, text files, SYSIN values, displayable numeric data.
COMP or BINARY	Binary storage controlled by the picture size and compiler truncation rules.	Counters, indexes, lengths, record counts.
COMP-3 or PACKED-DECIMAL	Packed decimal storage, two decimal digits per byte except the sign nibble.	Money, balances, quantities, packed fields in files and DB2 host variables.
COMP-5	Native binary storage using the full capacity of 2, 4, or 8 bytes.	System interfaces, binary lengths, fields shared with C or assembler.
COMP-1 and COMP-2	Internal floating-point data. These items do not use a PICTURE clause.	Scientific or engineering values with a wide range of scale.

DISPLAY usage

DISPLAY stores data in a readable external form. A numeric display field such as PIC 9(5) stores five digit characters. This is useful for printable reports, flat-file fields exchanged as text, and values that must be easy to inspect in a dump or editor.

01 WS-CUSTOMER-NO       PIC 9(5) USAGE DISPLAY.
01 WS-CUSTOMER-NAME     PIC X(30).

The tradeoff is arithmetic cost. When a display numeric field is used in arithmetic, COBOL must work with its numeric value rather than just its printable characters. For heavy calculations, binary or packed decimal fields are usually a better fit.

COMP and BINARY usage

COMP, COMPUTATIONAL, and BINARY are treated as binary forms in Enterprise COBOL. IBM documents the normal storage size as 2 bytes for 1 through 4 digits, 4 bytes for 5 through 9 digits, and 8 bytes for 10 through 18 digits.

01 WS-READ-COUNT        PIC S9(9) COMP VALUE 0.
01 WS-TABLE-SUB         PIC S9(4) COMP VALUE 1.

Binary fields work well for counters, subscripts, loop control, record counts, and lengths. Be careful with fields that leave your program in a file or message. Another program must use the same storage expectation, or the bytes will not mean the same value.

COMP-3 packed decimal usage

COMP-3 is the short form of PACKED-DECIMAL. Packed decimal stores two decimal digits in each byte, except the final half-byte also carries the sign. It is a common mainframe choice for money and business amounts because decimal precision matters.

01 WS-INVOICE-AMOUNT    PIC S9(7)V99 COMP-3.
01 WS-TAX-AMOUNT        PIC S9(5)V99 COMP-3.
01 WS-TOTAL-AMOUNT      PIC S9(8)V99 COMP-3.

IBM notes that packed decimal fields use storage most efficiently when they have an odd number of digits. For example, S9(7)V99 has nine digits, so the packed decimal bytes are used neatly with the sign nibble.

COMP-5 native binary usage

COMP-5 is native binary. IBM documents that a COMP-5 item can contain values up to the capacity of the binary field size, not only the value implied by the number of 9s in the PICTURE. This matters for interface fields.

01 WS-BUFFER-LENGTH     PIC 9(9) COMP-5.
01 WS-RETURN-CODE       PIC S9(9) COMP-5.

Use COMP-5 when a called routine, system service, C program, or assembler module expects a native binary value. Do not swap COMP and COMP-5 casually in a shared copybook. Check the compile options and interface rule first.

COMP-1 and COMP-2 usage

COMP-1 is single-precision internal floating point and COMP-2 is double-precision internal floating point. IBM documents COMP-1 as 4 bytes and COMP-2 as 8 bytes. These fields do not have a PICTURE clause.

01 WS-RATE-SHORT        USAGE COMP-1.
01 WS-RATE-LONG         USAGE COMP-2.

Floating point is not the usual choice for currency. Use packed decimal for account balances, invoice totals, interest posted to an account, and other business amounts where exact decimal behavior is expected.

How to choose the right usage

If the field is...	Usually choose...	Reason
Printed or read as text	DISPLAY	Readable and simple for reports, SYSIN, and display files.
A business amount	COMP-3	Keeps decimal arithmetic suitable for money and packed file fields.
A counter or subscript	COMP or COMP-5	Binary arithmetic is a good fit for whole-number loop values.
A field passed to C or assembler	COMP-5	Native binary values match many low-level interface contracts.
A scientific measurement	COMP-1 or COMP-2	Floating point supports a wide range of scale.

USAGE at group level

A USAGE clause can be specified at group level, and then it applies to elementary items inside the group. This can be useful, but it also hides detail. Many teams prefer coding usage on elementary numeric fields so copybook reviewers can see the storage format quickly.

01 WS-TOTALS.
   05 WS-ITEM-COUNT      PIC S9(9) COMP.
   05 WS-GROSS-AMOUNT    PIC S9(9)V99 COMP-3.
   05 WS-NET-AMOUNT      PIC S9(9)V99 COMP-3.

Do not mix usage casually in file copybooks. If a field is written to a dataset, another job may read the same bytes tomorrow morning. The data definition is part of the file contract.

Common mistakes

Using DISPLAY for every number

DISPLAY is easy to read, but it is a poor default for every calculated number. A record loop that adds totals millions of times should not use display numeric work fields just because the input file is display format.

Using floating point for money

Use COMP-3 for money unless your site has a specific rule that says otherwise. Floating point can represent a wide scale, but finance programs usually need exact decimal behavior.

Changing COMP to COMP-5 without checking interfaces

COMP-5 can use the full native binary capacity of the field. That is useful for interfaces, but it can change behavior compared with picture-limited binary fields. Test boundary values before changing a shared field.

Forgetting TRUNC and ARITH options

TRUNC affects binary items such as COMP and COMP-4. ARITH affects the maximum digits allowed in decimal arithmetic. Review compile options when a numeric field behaves differently after migration.

Related Mainframe Forum guides

For nearby topics, read COBOL Data Division complete guide, COBOL COMP-3 packed decimal, COBOL ARITH compiler option, COBOL TRUNC compiler option, and Working Storage vs Local Storage.

External references

IBM documents the USAGE clause, computational items, and numeric data storage.

FAQ

What is USAGE in COBOL?

USAGE tells COBOL how a data item is represented in storage, such as display, binary, packed decimal, native binary, or floating point.

Is COMP-3 the same as packed decimal?

Yes. In Enterprise COBOL, COMP-3 and PACKED-DECIMAL describe packed decimal storage.

When should I use COMP-5?

Use COMP-5 when a field must hold a native binary value, especially for system interfaces, C calls, assembler calls, lengths, and return codes.

Should money use COMP-1 or COMP-2?

No, not for normal business amounts. Money is usually better defined as COMP-3 because packed decimal fits exact decimal business arithmetic.

COBOL ARITH Compiler Option: COMPAT vs EXTEND with Decimal Examples

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).

Choose precision before compile.

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.
01 WS-TAX-AMOUNT          PIC S9(7)V99 COMP-3.
01 WS-INVOICE-TOTAL       PIC S9(10)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.
01 WS-INTEREST-RATE       PIC S9(3)V9(9) COMP-3.
01 WS-INTEREST-AMOUNT     PIC S9(18)V99 COMP-3.
COMPUTE WS-INTEREST-AMOUNT =
        WS-LARGE-BALANCE * WS-INTEREST-RATE

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.