If you suspect an error in your Enterprise PL/I application is
a storage overlay problem, check for the following:
- The use of a subscript outside the declared bounds (check the
SUBSCRIPTRANGE condition)
- An attempt to assign a string to a target with an insufficient
maximum length (check the STRINGSIZE condition)
- The failure of the arguments to a SUBSTR reference to comply with
the rules described for the SUBSTR built-in function (check the STRINGRANGE
condition)
- The loss of significant last high-order (left-most) binary or
decimal digits during assignment to an intermediate result or variable
or during an input/output operation (check the SIZE condition)
- The reading of a variable-length file into a variable
- The misuse of a pointer variable
- The invocation of a Language Environment callable
service with fewer arguments than are required
The first four situations are associated with the listed Enterprise
PL/I conditions, all of which are disabled by default. If you suspect
one of these problems exists in your routine, use the appropriate
condition prefix on the suspected statement or on the BEGIN or PROCEDURE
statement of the containing block.
The fifth situation occurs when you read a data record into a variable
that is too small. This type of problem only happens with variable-length
files. You can often isolate the problem by examining the data in
the file information and buffer.
The sixth situation occurs when you misuse a pointer variable.
This type of storage overlay is particularly difficult to isolate.
There are a number of ways pointer variables can be misused:
- When a READ statement runs with the SET option, a value is placed
in a pointer. If you then run a WRITE statement or another READ SET
option with another pointer, you overlay your storage if you try to
use the original pointer.
- When you try to use a pointer to allocate storage that has already
been freed, you can also cause a storage overlay.
- When you attempt to use a pointer set with the ADDR built-in function
as a base for data with different attributes, you can cause a storage
overlay.
The seventh situation occurs when a Language Environment callable
service is passed fewer arguments than its interface requires. The
following example might cause a storage overlay because Language Environment assumes
that the fourth item in the argument list is the address of a feedback
code, when in reality it could be residue data pointing anywhere in
storage.
| Invalid calls |
Valid calls |
|---|
DCL CEEDATE ENTRY OPTIONS(ASM);
CALL CEEDATE(x,y,z); /* invalid */
|
DCL CEEDATE ENTRY(*,*,*,* OPTIONAL) OPTIONS(ASM);
CALL CEEDATE(x,y,z,*); /* valid */
CALL CEEDATE(x,y,z,fc); /* valid */
|