MOVE_TO_LIT_NOTALLOWED — MOVE_TO_LIT_NOTALLOWED runtime error

This dump is raised by the ABAP kernel when a write operation targets memory the runtime has classified as a literal constant. Field symbols and dereferenced data references are generic pointers: at runtime they can be pointed at a variable, a structure field, a table row, or, less obviously, at a literal such as a quoted string, a numeric constant, or a value defined with CONSTANTS. Literals live in read-only program memory. Reading through a field symbol pointed at a literal is fine. Writing to it through MOVE, MOVE-CORRESPONDING, CLEAR, or a plain assignment via the field symbol is not, and the kernel terminates the statement rather than corrupt protected memory. The dump therefore always traces back to an ASSIGN statement, executed earlier in the same call stack, that pointed the field symbol or reference at something that was not a genuine variable.

If the cause is a literal used as a fallback default, change the code so the write path can never reach that branch: either check sy-subrc after the original ASSIGN and route real writes only to confirmed data objects, or replace the literal default with a properly declared dummy variable that can safely absorb a write. This is a code correction requiring a transport. If the cause is dynamic component resolution falling through, add an explicit check that the resolved component name exists on the structure (via RTTI or a documented list) before the ASSIGN COMPONENT, and re-check sy-subrc on every loop iteration rather than relying on the previous pass. If the cause is leftover debug code in a customer enhancement or BAdI, remove it and release through the normal change request process. If the failing include belongs to unmodified SAP standard code, do not touch the object directly; raise an incident with SAP and, if a production stop is needed immediately, identify and avoid the specific data or variant combination that reaches the literal branch as a temporary workaround, not a fix.

The reflex fix is to wrap the failing MOVE in a TRY/CATCH block, or an equivalent classic exception handler, and swallow the error so the program keeps running. This makes the dump disappear from the user's screen but does nothing about the underlying bug: the field symbol still never receives the value it was supposed to hold. The program continues executing with a stale, default, or literal value in a field the business logic assumes was just updated. The resulting data inconsistency surfaces later, often in a different transaction or a downstream report, and is considerably harder to trace back to its origin than the original dump would have been.

Flag the pattern ASSIGN literal TO field-symbol during code review and, where available, configure static checks such as Code Inspector or ABAP Test Cockpit to warn on it. Require that any ASSIGN used as a fallback default is followed immediately by an sy-subrc check before the field symbol is reused for a write. Cover every branch of dynamic component resolution logic with unit tests, including the failure branch, so a name mismatch is caught before transport rather than in production.

This is an ABAP development defect, not a Basis or functional configuration issue, since it originates in custom code, an enhancement, or a BAdI implementation performing an unsafe ASSIGN. Basis is only involved to help pull the ST22 dump and stack trace. If the failing include is unmodified SAP standard code, escalate to SAP support rather than assign it internally. The handover note should include the program, include and line from ST22, the ASSIGN statement identified above the failing line, and the transaction, variant, or data combination that triggers the branch.

Neighbouring dumps in the same family cover different flavours of bad field symbol or reference use: GETWA_NOT_ASSIGNED for writing through an unassigned field symbol, MOVE_CAST_ERROR for a type mismatch during a cast-style move, ASSIGN_LENGTH_0 for offset or length problems in a dynamic ASSIGN, and OBJECTS_OBJREF_NOT_ASSIGNED for the object reference equivalent. All of them are diagnosed the same way, by reading back from the failing statement to the ASSIGN or reference operation that set up the pointer.