About ABAP Generation, Loads, Includes and more

Context

This is a practical deep-dive into how ABAP sources become executable code, how that code is cached and invalidated, how includes are handled, and which public vs. internal APIs exist for building and analyzing programs dynamically.

1. Core concepts and lifecycle

1.1 Source → Load → Execution

• Source: ABAP source is stored in the database (table REPOSRC).
• Load: When a program is activated or first executed, the compiler generates an ABAP Load and stores it in table REPOLOAD. The load is the executable representation of the program.
• Execution: For performance, the load is copied from REPOLOAD into the Program Buffer (aka PXA - Program eXecution Area) in shared memory on each application server and executed from there.

Loads are regenerated when sources (or dependent artifacts like includes or DDIC types) change, after certain kernel updates (load format changes), or on first use after transport if no up-to-date load exists.

➡️ Also see: Understanding Program Load (ABAP Load)

1.2 Machine type (Platform ID) dependency

ABAP loads are platform-dependent. In heterogeneous landscapes you’ll find one load per platform (e.g., Windows x86_64, Linux x86_64, AIX) in REPOLOAD. When you activate a program on server A, only that platform’s load is generated; executing the same program on server B with a different platform triggers a (first-time) compilation there. If a platform is retired, obsolete loads should be cleaned up.

1.3 Program Buffer (PXA)

The PXA is a shared-memory cache of generated program loads, maintained per application server. It uses a hash structure and LRU displacement; swaps in ST02 indicate entries displaced from the buffer. Sizing is crucial for performance and stability.

Key profile parameters and facts:

• abap/buffersize: total PXA size (kB). Increase gradually (e.g., 10–20%) if you see many swaps or dump PXA_NO_FREE_SPACE.
• abap/pxa: mode of operation (e.g., shared, protect, generation modes). Use a protected mode to avoid memory overwrites.
• abap/buffer_fragments: number of fragments (1–16). Too many fragments can cause swaps even with free space; setting it to 1 can help if you observe uneven fill levels.

➡️ Also see: PXA (Program eXecution Area) - ABAP Program Buffer and Understanding Program Buffer (PXA).

2. Generation, invalidation, and SGEN

2.1 When is a load (re)generated?

• On activation of an object.
• On first execution if a valid load is missing in REPOLOAD or PXA.
• After dependent change (include, DDIC type, etc.) → dependent programs’ loads are invalidated and regenerated on next use.
• After kernel change when load format changes.

2.2 SGEN - Mass Generation

Use transaction SGEN to pre-generate loads after upgrades, SPs, kernel changes, or for new platforms. In heterogeneous systems, run SGEN once per platform. It’s normal to still see some compiling after SGEN (e.g., newly transported or rarely used objects).

3. The PXA in depth: preload, swaps, and fragmentation

3.1 Automatic preload at server startup

At startup the PXA is empty; to mitigate cold-start slowness, the kernel preloads programs recorded from previous runs:

• Files in workdir: pxanew, pxastat, optionally pxauserload (your fixed whitelist).
• Load order: pxauserload → pxanew → pxastat, up to the percentage in abap/pxa_preload (default nowadays 20%).

3.2 Swaps even with free space?

This typically points to fragmentation. Since 6.20 the PXA may be split into multiple fragments to improve parallel access. Due to hashing, some fragments can hit capacity (swapping) while others remain underutilized. Remedies:

• Apply kernel patches that improved the hash.
• Reduce fragments to 1 via abap/buffer_fragments = 1 so swaps occur only when the whole buffer is full.

A practical threshold: a few thousand swaps/day are typically tolerable; >10,000/day is a sign to increase abap/buffersize or adjust fragments.
Fragment size rules of thumb (as enforced by the kernel): up to 16 fragments; maximum fragment size ~4GB (pre-721) / ~2GB (since 721); minimum size ~300MB (pre-721) / ~500MB (since 721); the kernel auto-adjusts the fragment count to stay within min/max sizes.

3.3 Inspecting and resetting PXA

• ST02 (Program buffer area) → monitor swaps, hit rate.
• Developer trace shows PXA init and fragment info on startup.
• ABAP Debugger → System areas → PXAFRAG to display fragment stats.
• Reset program buffer with system OK-code $PXA (avoids flushing other buffers, unlike $SYNC).

4. Versioning, session pinning, and “LOAD_*” dumps

Within a user session, the runtime may pin a specific version of a program/class/interface that was current when it was first used. If later, a caller requires a newer version but the pinned one is still present (or the requested version was evicted), you may see dumps such as:

• LOAD_PROGRAM_LOST, LOAD_PROGRAM_CLASS_MISMATCH, LOAD_CLASS_VERSION_MISMATCH, LOAD_INTF_VERSION_MISMATCH, etc.
• Typical causes: dependency activation in another session or node, PXA eviction, or cross-server version drift in a cluster. Mitigation: ensure transports/activations complete across nodes; consider warm-up; avoid running with stale sessions during deployments.

5. Includes: concept, where-used, and reading content

5.1 What an include is

Includes are source units (program type “I”) that are textually included into main programs (report/class pool/module pool) at compile time. They help split large code bases and are not executable on their own. (General background.)

5.2 Where-used mapping

The system table D010INC tracks main program ↔ include relationships (MASTER, INCLUDE). This is useful when analyzing invalidation cascades and regeneration scope.

5.3 Reading include sources

Programmatically, includes are read like reports from REPOSRC:

DATA lt_src TYPE STANDARD TABLE OF string.
READ REPORT ‘ZMY_INCLUDE’ INTO lt_src.

Use READ REPORT for any ABAP program type (including includes).

6. Public vs. internal ABAP APIs for dynamic program work

6.1 Public & released statements

• READ REPORT - reads repository source into an internal table.
• SYNTAX-CHECK FOR itab ... - runs the ABAP syntax check on source provided in an internal table.
• INSERT REPORT prog FROM itab - writes/overwrites program source in the repository (use with care).
• GENERATE SUBROUTINE POOL itab NAME prog - compiles a temporary subroutine pool from source in memory; useful for safe dynamic execution patterns (with robust input validation).

6.2 Internal / not-released statements (for reference only)

• GENERATE REPORT - compile a repository program into a load. Internal only; do not use in application code.
• LOAD REPORT - load parts of a program from the repository; internal only.
• DELETE REPORT - delete program artifacts; internal only (use FM RS_DELETE_PROGRAM instead if you must).
• SCAN ABAP-SOURCE - scanner interface for tokenizing ABAP source; publicly documented and useful for analysis tools.

These internal statements are documented in SAP’s keyword docs as “for internal use only; do not use in application programs.” They are included here solely to clarify what happens at a low level.

7. Operating the Program Buffer (PXA): tuning checklist

Symptoms → Actions

• High swaps in ST02 (≫ a few thousand/day)
  → Increase abap/buffersize stepwise; if swaps persist with free space, reduce fragments (abap/buffer_fragments = 1).
• PXA_NO_FREE_SPACE dumps
  → Increase abap/buffersize, validate fragment count/size; consider $PXA to clear if needed.
• Inexplicable runtime errors (e.g., PXA_DESTROYED, odd CALL_FUNCTION_NOT_FOUND)
  → Ensure PXA protection (abap/pxa protect modes) and restart.
• Cold starts are slow after restarts
  → Use the preload: maintain pxauserload; confirm abap/pxa_preload (default currently 20%).
• Continuous compiling after SGEN
  → Normal in part (new/invalidated objects, other platforms). Run SGEN per platform; verify transports/activations.

8. Troubleshooting “LOAD_*” errors: quick map

• LOAD_PROGRAM_LOST - Program version in DB differs from what the session expects; often after PXA eviction or cross-server execution. Warm up or align versions across nodes.
• LOAD_*_MISMATCH (class/interface/typepool) - Caller expects an older/newer version than is present. Ensure activations/transport imports are complete; restart long-lived processes if needed.

9. Practical: end-to-end flow (activation to execution)

1. Developer activates program → load generated to REPOLOAD (for the current platform).

2. First execution on a given app server → load copied to PXA (or compiled if obsolete/missing).

3. Subsequent calls use the PXA copy until:

   • Evicted by LRU / swaps → fetched again from REPOLOAD.
   • Source/dep changes → PXA entry marked old; next call regenerates a fresh load.

4. Server restart → optional preload from pxauserload/pxanew/pxastat.

Appendix: useful tables, tools, and commands

• Tables: REPOSRC (source), REPOLOAD (loads), D010INC (include relations).
• Transactions: ST02 (PXA), ST22 (dumps), SGEN (mass generation).
• OK-codes: $PXA (reset program buffer), $SYNC (flush all buffers - use sparingly).
• Traces/Debug: Developer traces show PXA initialization & fragments; ABAP Debugger system area PXAFRAG shows live fragment stats.

References & further reading

• ABAP Load / SGEN overview (SAP Help Portal).
• ABAP Keyword Doc: GENERATE SUBROUTINE POOL, INSERT REPORT, READ REPORT, SYNTAX-CHECK.
• Internal statements (for reference only): GENERATE REPORT, LOAD REPORT, DELETE REPORT.
• PXA preload & files (pxanew, pxastat, pxauserload); default preload now 20%.
• Swaps despite free space / fragmentation (Note 1267828).
• Too many swaps - sizing rules & thresholds (KBA 2468124).
• Meaning of pxanew/pxastat (Note 23642).
• Program Buffer parameterization: abap/pxa, abap/buffersize.