Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

Greetings for the day!

I want to share with you a issue I recently faced during upgrade using SUM tool and how I managed to solve it .


Problem Summary


While performing SAP Upgrade I was faced with the error in the Execution Phase MAIN_NEWBAS/XPRAS_AIMMRG . My upgrade was halted at 80% !!

The error was : Checks after the phase MAIN_NEWBAS/XPRAS_AIMMRG were negative!

Detected aborted activities in the XPRASUPG.ELG.



Disclaimer : The screenshot is taken for issue explanation only. It does not contain any personal data of the system

I will list down below the troubleshooting steps I took :

Troubleshooting steps

As the error suggested there was problem in the phase "MAIN_NEWBAS/XPRAS_AIMMRG". My first step was to understand what this step meant "XPRAS_AIMMRG".

Upon reading further I could notice that XPRA or "Report after Put" is an ABAP program or Function Module that is executed during a transport request import sequence, the import of a Support Package and during Upgrades/Enhancement Package installations.The XPRA phase reports are run as one of the last steps of the upgrade.

During the reading of this part I got to know one vital piece of information.
TIP : All XPRAs are executed by a system job, named RDDEXECL


So I instantly knew where to look next 😉

Yes you guessed it right , it is the RDDEXECL job log!!!  🙂

But before jumping to conclusion , I instead followed the safe approach of check the logs and proceed step by step...

So my next step was to check the XPRASUPG.ELG which was mentioned in the error screenshot above.

The information in the XPRASUPG.ELG :-

The entries in the XPRASUPG.ELG were :-

A4 ERSAU 570 Update rules "F4J8O9JDEWJZC7LT4H0BF275B" read in version "D"
A4 ERSAU 570 Update rules "F4MM541PERP7WSNK8T32LR8H5" read in version "D"
A4 ERSAU 570 Update rules "F4TM9JFI13PM2A445BP5WJ5H5" read in version "D"
A4 ERSAU 570 Update rules "F5JPKIBC381H1WEHRMYPNJICG" read in version "D"
A4 ERSAU 570 Update rules "F5L2BHAN9AUCY8BJ9NIXUZQ23" read in version "D"
1AETR012XProgram canceled (job "RDDEXECL", number "15134100")
1AEPU320 See job log"RDDEXECL""15134100""<SID of system>"
1 ETP111 exit code : "12"


As you and I guessed the next step was to check what happened with the RDDEXECL job ?

I start looking in the RDDEXECL job log, the entries in the job log were :-

Job log overview for job: RDDEXECL

|Job log |Time |Message text uncoded |Message ID||Msg.typ|
|12.09.2018|10:17:34|Job started | 00 | 516 | S |
|12.09.2018|10:17:34|Step 001 started (program RDDEXECL, variant , user ID DDIC) | 00 | 550 | S |
|12.09.2018|10:17:34|All DB buffers of application server <hostname of the application server> were synchronized | PU | 170 | S |
|12.09.2018|10:26:22|Replication completed successfully | <>| 033 | S |
|12.09.2018|10:27:23|Replication completed successfully | <>| 033 | S |
|12.09.2018|10:27:48|Internal session terminated with a runtime error LOAD_NO_ROLL (see ST22)| 00 | 671 | A |
|12.09.2018|10:27:48|Job cancelled | 00 | 518 | A |


>>> With this information I had hit the biggest hint to solve my problem 😉
The problem occurred due to the run time error "LOAD_NO_ROLL "


This was the final piece of information I needed to start my journey towards solving the issue.


Steps to resolve the issue :-

Now that I have all the necessary information required to resolve the issue , I changed few memory parameters and this helped me resolve the issue.

So the question now is which memory parameters did I change and why ?

1. As soon as I saw the LOAD_NO_ROLL dump I checked in ST22 to find out more about the dump.


The dump details are :-

Category Resource Shortage
Runtime Errors LOAD_NO_ROLL
Date and Time 12.09.2018 15:24:35

Error analysis |
| This is probably due to a very large dataset, for which there are |
| insufficient resources in your installation. |
| When loading a program, 435456 bytes of storage space was |
| needed, but this was not available. |
| Last error logged in SAP kernel |
| |
| Component............ EM |
| Location.......... SAP-Server <application server> on host <application server> (wp 31) |
| Version.............. 37 |
| Error code............ 7 |
| Error text............ Warning: EM-Memory exhausted: Workprocess gets PRIV |
| Description............ |
| System call.......... |
| Module.............. D:/depot/bas/749_REL/src/krn/em/emxx.c

With this information I knew where the problem was present.

" The line : Error text............ Warning: EM-Memory exhausted: Workprocess gets PRIV

Is the final point where we need to focus on!! "



As the entry indicates the extended memory in the application server got exhausted and this resulted in failing of the job.

To quickly revise the flow of the error is :
Extended memory gets exhausted --> LOAD_NO_ROLL runtime error occurs --> the job RDDEXECL fails --> this is indicated in the XPRASUPG.ELG --> Upgrade is halted in phase 'XPRAS_AIMMRG'


My next step was to check in ST02 to see what was the status of extended memory status.


Disclaimer : The screenshot is taken for issue explanation only. It does not contain any personal data of the system

In my system I could see the filed extended memory (marked by green) got exhausted.
The fields that need to be looked are Max Use (KB) and In Mem (KB).

If the fields Max Use (KB) and In Mem (KB) are same i.e the values in these fileds are same it means that extended memory is exhausted.


As a next step you need to increase the extended memory for the application server in which you are facing the issue.

The extended memory parameters are em/initial_size_MB (for non-AIX ) and EM/TOTAL_SIZE_MB ( for AIX only ). I increase the value for these parameters and rerun the upgrade phase and could see that the issue is resolved.


I will summarize the steps here :-

1. Identify from the job log what is the cause of the issue.

2. Check in the releavant dump file in ST22.

3. For LOAD_NO_ROLL dump check in ST02 to locate the extended meory usage.

4. Increase the value for extended memory accordingly.

While analysing the issue there were couple of SAP wiki links and SAP notes/KBA's I gained knowledge from. I am sharing the following information here :-

SAP wiki :

SAP notes/KBAs

1680814: "EmAlloc failed" and other memory allocation problems
2085980: New features in memory management as of Kernel Release 7.40


Please let me know in case any issues/queries.