I studied COBOL, I know it's history, but I never used it professionally. I went from BASIC, to FORTRAN, to assembly, to FOCUS, to C, C++, Java, Javascript, to Python with various flavors of SQL along the way. Never did have a chance to really try out COBOL.
I did feed your comments to ChatGPT and it came back with this:
You’re right — any old-school mainframe COBOL programmer will wince a little when they see that 😊
Here are the two classic problems with those definitions:
01 WS-RECORD-COUNT PIC 9(5) COMP-3 VALUE ZERO.
01 WS-PAGE-COUNT PIC 9(4) COMP-3 VALUE ZERO.
01 WS-LINE-COUNT PIC 9(3) COMP-3 VALUE ZERO.
1️⃣ They’re Too Small (Overflow Risk)
PIC 9(5) → max 99,999
PIC 9(4) → max 9,999
PIC 9(3) → max 999
For a DB2 batch job reading potentially large parent/child result sets, those limits are dangerous.
If:
You process 150,000 records → WS-RECORD-COUNT overflows
You print more than 9,999 pages → WS-PAGE-COUNT overflows
You accidentally mis-handle pagination → line counter can wrap
On many mainframes, packed decimal overflow results in:
S0C7 abend
corrupted totals
negative values due to wraparound
Seasoned COBOL programmers typically over-allocate counters:
PIC 9(9) COMP-3
because storage was cheap compared to a batch failure.
2️⃣ Using COMP-3 for Loop Counters Is Questionable
COMP-3 = packed decimal (BCD)
That’s ideal for:
money
financial arithmetic
values requiring exact decimal math
But for simple counters, especially ones used in:
PERFORM VARYING
ADD 1 TO ...
indexing logic
it’s not ideal.
Better choices traditionally were:
PIC S9(9) COMP (binary)
or
PIC S9(9) COMP-5 (true binary, depending on compiler)
Why?
Binary arithmetic is faster.
Packed decimal arithmetic costs more CPU.
Counters are integer loop controls, not financial quantities.
In older z/OS batch environments, this absolutely mattered.
What an Experienced COBOL Programmer Would Likely Write
01 WS-RECORD-COUNT PIC S9(9) COMP VALUE 0.
01 WS-PAGE-COUNT PIC S9(7) COMP VALUE 0.
01 WS-LINE-COUNT PIC S9(4) COMP VALUE 0.
or even:
01 WS-RECORD-COUNT PIC S9(9) COMP-5 VALUE 0.
depending on shop standards.
Bonus Old-School Observation
Another subtle issue:
They’re unsigned (9(n) not S9(n)).
Arithmetic that accidentally goes negative could cause odd behavior.
Many shops defaulted to signed numeric for counters as defensive practice.
So Your Instinct Is Correct
The two classic problems are:
Insufficient size → overflow risk
Using COMP-3 (packed decimal) for simple counters instead of binary
Even today, on Enterprise COBOL for z/OS, those considerations still apply — though modern hardware makes the performance gap less dramatic than it used to be.
If you’d like, I can also show how a modern Enterprise COBOL shop would define these today.
= new reply since forum marked as read