Professional Documents
Culture Documents
This chapter explains how your programs can produce illegal code and describes how you can identify and fix
such errors. It describes the different types of protection violation you could encounter when using this COBOL
system, and shows you how to identify and eliminate them.
Introduction
This COBOL system attempts to prevent or trap potentially illegal code. However, it is still possible for your
programs to generate code that is illegal in some way, and when this happens the error might be trapped as a
general protection violation by the operating system, or as a COBOL protection violation by this COBOL
system.
• The instruction is not recognized by the processor (as is the case if data is executed as if it were a
procedure)
• A valid instruction references a memory location or other resource that is invalid in the context of the
currently running process.
A general protection error is an error caught by the operating system. The operating system
determines the context for general protection violations.
A COBOL protection error is an error caught by the COBOL system, although the error might be
trapped when running a non-COBOL program. The COBOL system determines the context for COBOL
protection violations.
• The primary effect is that a statement in the program returns an incorrect result. If the application does
not use that result, you will not notice a problem. However, if subsequent execution relies on the value
returned by that statement, the program might exhibit unexpected behavior.
• The possible secondary effects depend on the memory area that your program modifies:
o If the memory area lies in an unprotected COBOL system area, the COBOL system might
exhibit unexpected behavior, including that resulting from executing data as if it were
procedure. This could lead to a general protection violation or infinite loop.
o If the memory area lies in the program area, the program could produce incorrect results or
fail at a later point as a result of a legitimate access to the memory area that had previously
been corrupted.
• Stack overflow
The following sections describe each of these problems and how to fix them.
• The number, size, and usage of parameters in the calling program; these must match those in the
called program
• The REFERENCE, CONTENT, and VALUE clauses in the calling program; these must match the
definitions of the parameters in the called program
It becomes more difficult to manage such factors when one of the calling or called programs is not COBOL. As
a result, protection violations are more likely in such applications. You must ensure that the non-COBOL
language conforms with the default calling convention for COBOL, or COBOL conforms to the calling
convention of the non-COBOL language (by using the CALL-CONVENTION clause). See the chapter The
COBOL Interfacing Environment for more information on the CALL-CONVENTION clause.
The effects of a mismatch in the calling interface between two programs can be extremely varied depending on
the interaction between the mismatch in question and the calling conventions used.
Stack Overflow
A less obvious cause for a general protection violation is stack overflow. The stack is the system area in which
called parameters and the calling program's return address are temporarily stored for a CALL statement. Stack
overflow occurs when the level of nesting of called subprograms, or the size or number of passed parameters,
is greater than the stack can manage.
Stack overflow can occur due to excessive use of the stack, or because the default or requested stack size is
small. You should bear in mind that operating system support routines might also make use of the stack and
reduce its effective size, and that different versions of the same operating system can make different use of the
stack, thus varying its effective size.
If one of your programs causes a general protection violation when you run it on a different version of an
operating system, you could consider increasing the default stack size. Stack overflow is very rarely a problem
on UNIX environments. If you suspect you need to change the size of your stack on UNIX, see your UNIX
system documentation for details of how you can do this.
• In the program's procedure area, the operating system might trap a general protection violation.
• Outside of the address range allocated to the program, this COBOL system produces a run-time
system error 114 "Attempt to access item beyond bounds of memory".
Example:
In the following example, the reference modification results in run-time system error 114 "Attempt to access
item beyond bounds of memory" when run. This is caused by setting a to be greater than the maximum length
of b. The first use of a reference modified item is a source field, so results in incorrect data being passed into c.
This problem is detected by this COBOL system.
The second use of a reference modified item is potentially more dangerous, as the reference modified item is a
target field. Again, this COBOL system detects this problem and produces run-time system error 114 "Attempt
to access item beyond bounds of memory").
This example is used in the following sections to illustrate how to debug the program in various environments.
program-id. "Buggy".
Working-storage section.
01 a pic 9(6).
procedure division.
move 999999 to a
call "bug" using a
stop run.
end program "buggy".
program-id. "bug".
working-storage section.
01 b pic x(20).
01 c pic x.
linkage section.
01 a pic 9(6).
procedure division using a.
move b(a:1) to c
move "1" to b(a:1)
exit program.
Example:
In the following example, data item undefined-pointer is defined as a pointer to a procedure, but is not
given a value before it is used. As a result, the CALL statement fails, giving run-time system error 114
("Attempt to access item beyond bounds of memory").
working-storage section.
01 undefined-pointer usage procedure-pointer.
procedure division.
call undefined-pointer
stop run.
Subscript Out of Range
The values of subscripts and index items are checked by this COBOL system, with run-time system error 153
"Subscript out of range" given if they are out of range. However, checking subscripts and index items
decreases the performance of your application to some extent. To avoid this decrease in performance you can
use the NOBOUND directive to disable such checking. If the NOBOUND directive is used and a subscript or
index item is out of range when referencing a table, a protection violation might occur.
If you get unexpected results or a protection violation error in an application that has been compiled or
generated with the NOBOUND directive, you should recompile the program without the directive and rerun it to
determine if the fault is caused by a subscript error.
Example:
The following programs show how you can experience unexpected results as a result of inadvertently using an
out of range subscript when the NOBOUND directive is specified. Because of the value passed from Bound-
main, Build-sub moves "1" to the 21st element of an array that is only 20 elements in size. Because the
NOBOUND directive is specified, this COBOL system permits this operation, which overwrites the next data
item, c. If the NOBOUND directive was not set, the COBOL system would have given run-time system error
153 ("Subscript out of range") when the MOVE was performed.
Before Modification
Program-id. "Bound-main".
Working-storage section.
01 a pic 99.
Procedure division.
move 21 to a
call "bound-sub" using a
stop run.
end program "bound-main".
After Modification