COMPUTE_INT_ZERODIVIDE — COMPUTE_INT_ZERODIVIDE runtime error diagnosis
COMPUTE_INT_ZERODIVIDE is an ABAP runtime error raised when a program divides an integer value by zero using DIV, MOD, or the arithmetic division operator, and the resulting CX_SY_ZERODIVIDE exception is not caught. The fix depends on whether the zero divisor comes from missing master data, an empty internal table, or a coding gap that never checked the divisor before using it.
This page covers the COMPUTE_INT_ZERODIVIDE short dump: what the CX_SY_ZERODIVIDE exception behind it means, the recurring real-world causes ordered by frequency, and how to read the ST22 dump to find the offending line and variable. It also separates the correct fix path by root cause from the common reflex of blanket-catching the exception, which hides the problem instead of solving it.
Published 16 Sept 2026· 1,287 words
What the dump means
This dump fires when ABAP code performs an integer division, a MOD operation, or a plain arithmetic division where at least one operand is typed as an integer, and the divisor evaluates to zero at runtime. The kernel raises the exception CX_SY_ZERODIVIDE, and if no TRY/CATCH block or CATCH SYSTEM-EXCEPTIONS statement is present around the operation, the exception propagates uncaught and the session terminates with a short dump. This is the integer sibling of COMPUTE_BCD_ZERODIVIDE, which covers the same situation for packed decimal fields; the two are functionally identical failures distinguished only by the data type of the divisor. The dump itself never indicates a bug in the ABAP runtime; it always means a calculation was written or fed data on the assumption that a denominator would never be zero, and that assumption was false at the moment the statement executed.
Root causes that actually produce it
- Missing zero check in custom code: by far the most common cause. A Z-report, interface, or BAdI implementation calculates an average, percentage, or ratio and divides by a quantity, count, or duration field without first testing IF divisor <> 0. This is almost always custom or modified code, rarely SAP standard.
- Empty internal table used as a divisor: a SELECT or table operation returns zero rows because of missing configuration, a wrong period, deleted master data, or overly restrictive selection criteria, and the program then divides by LINES( itab ) or a SUM/COUNT derived from that empty table without checking it first.
- Master data with a zero or blank conversion factor: unit of measure conversion factors, lot size fields, or pieces-per-container values pulled from material or logistics master data are zero or unmaintained, and custom logic uses them directly as a denominator.
- Unmaintained configuration driving an apportionment or quota calculation: a custom Z-table holding percentages, weighting factors, or quota arrangements has a row with a zero base value, and allocation logic divides cost or quantity by that base.
- Currency or quantity conversion routines with a zero exchange or conversion rate: a rate table entry exists but carries a factor of zero, or the rate record for the required date is missing and a default of zero is substituted somewhere upstream.
- MOD with a configurable batch size or split factor defaulted to zero: batch-splitting or round-robin distribution logic reads a batch size from customizing that was never populated, and the modulo operation divides by it directly.
- Enhancement or user-exit inserted by an earlier project that divides by a customer-specific field which is not always populated, surfacing only for a subset of records or a specific plant, company code, or document type.
What to inspect in ST22
- Header block: date, time, user, transaction code, program name, include, and line number. This is enough to jump straight into the editor at the exact failing statement.
- Error analysis text: confirms the exception class CX_SY_ZERODIVIDE and states which operator triggered it, DIV, MOD, or division.
- Source code extract: the highlighted statement shows the exact variable names on both sides of the operator; note the name of the divisor variable before doing anything else.
- Active calls and events (call stack): shows whether the failing statement sits in standard SAP code, a customer include, a BAdI implementation, or a user-exit, and identifies the calling transaction, report, or background job that led to it.
- Contents of system fields and local variables at the point of the dump: check the actual runtime value of the divisor and any related fields, and the return code of the SELECT or table operation that populated it.
- Follow-on work: open the program in SE38 or SE80 at the recorded line, trace the divisor's origin with SE16N or ST05 against the source table, and if the failure came from a background job check SM37 for the variant and selection parameters used.
Resolution path
If the cause is a missing zero check in custom code, add an explicit guard before the division and decide what the business-correct behaviour is when the divisor is zero: skip the record, default the result, or raise a meaningful application exception instead of letting the runtime dump. This requires a code change under a transport and normal testing in the development and QA systems. If the cause is master data with a zero or missing conversion factor, correct the master record; this is a functional fix and usually needs no transport unless the load or maintenance routine also lacks validation and should get one. If the cause is an empty internal table feeding the divisor, fix the upstream selection criteria or configuration that produced zero rows, and add a count check in the code as a defensive measure. If the cause is a configuration table with an unmaintained base value, correct the entry through the relevant customizing transaction. If the cause traces to a BAdI or user-exit from an earlier project, evaluate whether that enhancement is still needed, patch it under change control, and retest before transporting to production.
The fix people try first (and why it fails)
The reflex fix is to wrap the division in a generic TRY block catching CX_ROOT or CX_SY_ZERODIVIDE and letting execution continue, often substituting a hardcoded zero or one for the result without ever asking why the divisor was zero. This stops the dump but the program now silently produces a wrong average, a wrong allocation percentage, or a wrong converted quantity, and that bad number flows into downstream postings or reports with no error trail at all. The original data or configuration problem remains unaddressed and resurfaces later as a reconciliation discrepancy that is far harder to trace than the dump ever was.
Prevention
Make a zero check before division a standard code review item for any calculation touching quantities, counts, percentages, or rates, and enforce it through static checks such as the ABAP Test Cockpit or an extended syntax check profile flagging unguarded division operators. Where a zero divisor is a legitimate business scenario, code should raise a specific, catchable application exception with a clear message rather than let the runtime error surface. For master-data-driven divisors, add validation at the point of data maintenance so a zero conversion factor or quota base cannot be saved in the first place.
Whose problem this is
This is primarily an ABAP development issue since the dump originates in code, but functional input is needed to confirm whether a zero divisor should ever be possible in the business scenario, and to correct master data or configuration if that is the actual source. Basis involvement is limited to cases tied to a scheduled job. The handover note should state the program, include, and line, the name and expected source of the divisor field, and the business condition under which it was zero.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-abap-dumps/compute-int-zerodivideERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.