05 FILLER OCCURS 11584 TIMES.
10 TEST-STRING PIC X(11584).
01 FIRST-TIME-FLAG PIC X VALUE "Y".
01 DISP-BEFORE-STRING COMP PIC 9(8).
01 LOOP-COUNTER COMP PIC 9(8).
05 FILLER OCCURS 0 TO 11584 TIMES
DEPENDING ON DISP-BEFORE-STRING.
10 FILLER PIC X.
05 THE-SUBSTRING PIC X(12).
01 INITIAL-STRING PIC X(12)
VALUE "HELLO WORLD!".
01 STRING-PARAMETER PIC X(11584).
01 THE-RESULT PIC X.
PROCEDURE DIVISION USING
IF FIRST-TIME-FLAG = "Y"
GREATER THAN 11584
EQUAL TO TEST-STRING
( LOOP-COUNTER )
EQUAL TO TEST-STRING ( LOOP-COUNTER )
MOVE "Y" TO THE-RESULT
MOVE "N" TO THE-RESULT
EQUAL TO 11584
MOVE 11584 TO DISP-BEFORE-STRING
MOVE SPACE TO START-STRING
MOVE LOOP-COUNTER TO DISP-BEFORE-STRING
MOVE INITIAL-STRING TO THE-SUBSTRING
MOVE START-STRING TO TEST-STRING
( LOOP-COUNTER + 1 )
MOVE "N" TO FIRST-TIME-FLAG
A little knowledge can be a dangerous thing.
It can be faster to do one large compare than a lot of small compares; IBM's Enterprise COBOL (up to Version 4.2) can have a maximum WORKING-STORAGE of 128MB (Version 5.0 can have 2GB); LOCAL-STORAGE offers a further 128MB if you need more space.
The task is to confirm that a 11584-byte piece of storage has the value "HELLO WORLD!" somewhere, and the rest is space.
The, fictitious, programmer decides to write a sub-program for this (just in case it is needed elsewhere), and to include their high-performance technique (bonus).
The programmer calculates that 11584 * 11584 is 128MB, so uses WORKING-STORAGE for a huge table, and LOCAL-STORAGE for everything else that is needed.
The programmer codes it up, and smiles knowingly to themselves when the compile is clean. They were right about the 128MB.
Tests the code. It works. Possibly a little slow, but there's a heavy load on machine. Smiles again, thinking how slow it would be if coded without their level of expert knowledge.
The WORKING-STORAGE comes in at 134,189,056 bytes, and there's a good few bytes of other stuff as well. Should be large enough.
The reality is that doing a long compare instead of a short compare, as implemented here, is a very slow way to do it.
Even slower, the LOCAL-STORAGE, which is initialised by run-time routines every time a sub-program is called, causes the entire 128MB to be set up for each CALL.
The programmer was just plain wrong about the size of the table, there is enough room without using LOCAL-STORAGE. Long compares can beat short compares, but only when the actual number of compares is reduced.
I considered swapping the LOCAL-STORAGE and WORKING-STORAGE around, it is just far less likely someone would code it that way round, so I didn't. Putting a VALUE SPACE on the table (if it had been in LOCAL-STORAGE) would have initilised the table twice on each CALL, so even slower.
The Bloat can't be removed, without rewriting the program. Most of the code is bad, though there is one useful technique.
This is not a real-life example, but I can imagine someone doing it, if that someone is clever enough :-)
Compiling is no problem at all. Running it with every possibility quickly proves to be not worth attempting.
Of course, there is a plain old Bug as well. A very common one in "searching" tasks.