COMPUTE_INT_PLUS_OVERFLOW — COMPUTE_INT_PLUS_OVERFLOW dump explained

COMPUTE_INT_PLUS_OVERFLOW is a runtime error raised when the ABAP runtime attempts an addition, or an implicit increment such as ADD 1 TO or a loop counter update, and the mathematical result no longer fits in the target field's integer type. For a standard TYPE I field the usable range is roughly minus 2.1 billion to plus 2.1 billion; once a sum crosses that boundary the operation cannot be represented and the runtime terminates rather than silently wrapping the value. The exception class behind it is CX_SY_ARITHMETIC_OVERFLOW. It is a distinct dump from COMPUTE_BCD_OVERFLOW, which applies to packed decimal fields and has a much larger practical range, so the two point to different classes of problem even though the symptom name looks similar. This dump is a data-type or logic-flow limit being hit, not a database or authorization issue.

If the cause is a runaway loop, fix the exit condition or the recursion termination logic in the custom code; this is a code correction and needs a transport through the normal change process, tested against the scenario that triggered the infinite iteration. If the cause is an undersized data type for legitimate volume, change the field declaration to a wider integer type or to a packed type with sufficient length, and re-check every other place that field is used for type consistency; this also requires a change request and regression testing since the field may be a structure component used elsewhere. If the cause is garbage input from an uninitialized field symbol, fix the assignment logic so the field symbol is always bound before use, and add a defensive check; this is a code fix, not a data fix. If the cause is a genuinely huge but valid external value, add explicit range validation before the addition and reject or split the batch rather than letting the runtime enforce the limit. Standard SAP code producing this dump under normal volumes is rare and should be raised through the standard support channel rather than patched locally.

The reflex is to widen the data type, from TYPE I to a bigger integer or a packed field, and redeploy without asking why the value got that large in the first place. This makes the symptom disappear for a while but if the real cause is a runaway loop, the job now runs even longer before it eventually hits the new, larger ceiling, consuming far more work process time and background resources in the meantime. Wrapping the addition in a TRY CATCH block and silently ignoring the exception is worse: it hides the overflow entirely and the accumulated value becomes wrong from that point forward, corrupting downstream totals without any error trail.

Enforce a code review rule that every WHILE or DO loop has a visibly bounded exit condition, and that counters intended to track business volumes are sized against realistic production data, not test data. Add explicit sanity assertions on accumulator values in custom mass-processing code so an abnormal growth trend is caught early rather than at the integer ceiling. Where interfaces pass numeric values from external systems, validate the range on entry rather than trusting the source. Monitor long-running background jobs for runtime creep over time, since a gradually lengthening runtime on the same job is an early warning of a loop that no longer terminates cleanly.

ABAP development owns this when the failing code is custom; the handover note should include the program and line from ST22, the operand values at failure, and whether the job's runtime has been growing over recent executions. Functional consultants get involved only to confirm whether the data volume behind the dump is expected business activity or itself abnormal. Basis involvement is limited to job scheduling context in SM37 unless the dump correlates with a memory or performance escalation.

COMPUTE_BCD_OVERFLOW is the packed-number equivalent and is more common in financial amount fields; COMPUTE_INT_ZERODIVIDE shares the same arithmetic exception family but comes from division rather than addition. CONVT_OVERFLOW often appears alongside it when a value is moved into a field too small to hold it before the addition even happens. ITAB_ILLEGAL_INDEX and TABLE_INVALID_INDEX sometimes accompany the same runaway loop that produces this dump, since a broken exit condition frequently drives both an index and a counter out of bounds together.