Accelerator Manual (G06.24+, H06.03+)

Preparing Your Program for TNS/R Systems
Accelerator Manual—527303-002
2-2
Checking Segment Limits
Detection Guideline
•
Examine source code that explicitly disables overflow traps to make sure it tests for
arithmetic overflow with the $OVERFLOW function. Also look for user-written trap
handlers that return after an overflow. It is good coding practice always to test for
overflow, not just after multiplication and division operations.
Required Changes
•
Programs where multiplication or division operations may overflow must explicitly
test for overflow and establish the desired overflow answer. Programs can test for
overflow by:
•
Using the TAL $OVERFLOW function or the COBOL85 ONSIZE error clause
immediately after the arithmetic statement that might overflow
•
Examining the bits of the operands
•
Refer to the Guardian Programmer’s Guide for information on writing overflow
traps handlers.
Example
The following TAL code explicitly tests for overflow.
FIXED(0) count, time, result;
CODE (RDE; ANRI %577; SETE); ! Disable overflow traps
result := count * time;
IF $OVERFLOW THEN ! Test immediately for overflow
result := 0D; ! Fix the overflow result
Checking Segment Limits
On TNS systems, segments consist of 64 (2048-byte) memory pages, while on TNS/R
systems, segments consist of 32 (4096-byte) memory pages. TNS systems check
segment address boundaries to a byte boundary. TNS/R systems check segment
addresses to a memory page boundary. As a result of these differences, addressing
past the end of segments fails differently, depending on the system. You can notice this
difference when debugging addressing errors.
Detection Guidelines
•
On TNS systems, programs that exceed their segment’s logical limit fail
immediately, and on TNS/R systems they might not fail immediately. Results are
unpredictable.
•
On TNS/R systems, programs that reference data between the logical end of a
segment and the next 4 KB memory page boundary continue executing without an
exception.