SYSTEM_NO_ROLL — SYSTEM_NO_ROLL runtime error

SYSTEM_NO_ROLL belongs to the resource-shortage category of runtime errors, alongside the TSV_TNEW family and MEMORY_NO_MORE_PAGING. Roll memory is the area the kernel uses to save and restore a user's ABAP context when a work process is reassigned between dialog steps, and it is also consumed as call-stack depth grows during nested PERFORM, CALL FUNCTION, and method calls. When the kernel tries to allocate roll memory for a context switch or a new stack frame and none is available, either because the instance-wide roll file is full or because the requesting program has pushed the stack unusually deep, the kernel aborts the step and raises this dump rather than let the work process hang. It is a systemic symptom: the program that triggers the dump is often not the program that is misbehaving.

If the ST02 trend shows the roll file consistently near capacity during peak periods, the fix is a basis sizing change: increase the roll file size and related roll parameters, which requires a change request and typically an instance restart to take effect. If the call stack in ST22 shows deep repeated recursion, the fix belongs to the ABAP owner of that program: add or correct a termination condition, cap recursion depth, or restructure the logic to an iterative form, then transport the correction. If extended memory exhaustion is the trigger, address the extended memory shortage directly, following the same path as for TSV_TNEW type dumps, since fixing roll parameters alone will not stop the fallback. If the cause is a burst of parallel background or RFC processing, the fix is scheduling discipline, spreading the jobs or reducing parallel degree, which is a functional or basis process change rather than a code change. Do not change roll parameters and recursion fixes in the same transport; verify each independently so the next occurrence can be attributed correctly.

The reflex is to bump ztta/roll_area or the roll file size parameters and restart the instance, treating every SYSTEM_NO_ROLL as a sizing problem. When the real cause is a recursive custom program, the larger roll file only buys time before the same program consumes it again, and the dump returns under slightly heavier load with a worse diagnosis lag because the sizing change masked the pattern for weeks. Equally common is restarting the affected work process or the whole instance, which clears the symptom instantly but destroys the only evidence, the live call stack, needed to identify recursive code before the next occurrence.

Track roll area and extended memory utilization trends in ST02 over time rather than only reacting to a threshold alert, since roll shortages usually build gradually as user or batch load grows. For custom development, enforce a code review standard that every recursive routine has an explicit, testable depth or termination bound, and flag any function module or method that calls itself directly or indirectly. Review roll and extended memory profile parameters whenever user counts, batch job volume, or parallel processing degree change materially, not only after an incident.

Basis owns roll and extended memory profile sizing and instance-level capacity trends; ABAP owns any recursive or deeply nested custom code identified in the call stack. The handover note should state the ST02 utilization trend for the days leading to the dump, the full ABAP call stack with repeat counts, the work process load from SM50 or SM66 at dump time, and whether a parameter change or a code fix was applied, so the next occurrence can be compared against a known baseline.

Closely related to TSV_TNEW_PAGE_ALLOC_FAILED, TSV_TNEW_BLOCKS_NO_ROLL_MEMORY, and TSV_TNEW_OCCURS_NO_ROLL_MEMORY, all resource-shortage dumps but tied to extended memory rather than roll memory specifically. MEMORY_NO_MORE_PAGING sits in the same family for paging area exhaustion. TIME_OUT can appear alongside it when a starved work process also exceeds its maximum runtime while waiting for memory. The tables and monitors involved are kernel and profile-level rather than application tables: ST02 memory statistics and the active instance profile.