This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.


If you haven’t already seen it, quite some time ago I wrote a brief blog post on the Flight Recorder for the NW AS Java stack.
Many years later, I’ve still very rarely seen a company use the flight recorder information.
Snapshots (also known as SAP Kernel Snapshot) in the NW AS ABAP stack are much the same thing.

When a serious condition occurs within the ABAP stack, a system message is registered in the system log (SM21) and a snapshot of the current system status is generated.
An example condition could be that a work process has died without warning, or that there was a lack of resources (background or dialog), hard shutdown of the SAP system/server or that the dispatcher queue was full.

Each of these scenarios is logged under system log message code “Q41”, in category “DP” and “Process No” “000”.
The only difference between the failures is the text following “reason: “ which is passed in by the calling Kernel function.

Q41 in system log

According to the SAP notes, the initial feature was provided in 2013 as per SAP note: 1786182 “CreateSnapshot: Collecting developer traces using sapcontrol”.
It was provided as an additional set of web service functions on the SAP instance agent (sapstartsrv) and is therefore accessible from outside of the SAP system if need be.

Originally, it appears to have been designed to be operated independently outside the SAP system, however SAP note 2640476 – “How to analyze Server Snapshot with kernel snapshot analyser” from 2019, indicates that it was integrated into the SAP Kernel in 7.40 (i.e. that the Kernel itself can instigate the snapshot).

How can we use SNAPSHOTS?

You can either access the snapshot zip files directly on the O/S level using O/S commands to extract and inspect the files, or you can use the ABAP transaction code SNAPSHOTS to see an ALV list of snapshot files.

In the O/S the files are stored in /sapmnt/<SID>/global/sapcontrol/snapshots.

Usually, the sequence of access is dictated by an extraordinary event within the ABAP stack, then you may see the System log entry which will inform you of the existence of a snapshot, but you may choose to regularly check in SNAPSHOTS anyway as part of your daily checks.


As you can see the ABAP transaction incorporates the reason for the snapshot, whereas the O/S file listing is not so easy to identify.
If you want to use the O/S level, then unzipping the file will reveal a file called “description.txt” which states the reason for the snapshot:

From the SNAPSHOTS transaction (program RS_DOWNLOAD_SNAPSHOTS) you have the option to download the snapshot file to your front-end.
Here you can unzip the file and expose the contents.

Once you have extracted the snapshot zip file, you will see a tree structure under which will sit a number of XML files:

The names of the XML files are fairly self explanatory.
ABAPGetWPTable for example, is the name of the sapcontrol web service function that is used to get the ABAP Work Process Table (same as transaction SM50).

Opening any of the XML files is going to be a lot easier with Microsoft Excel.
Except the XML is not suitable for Excel without a little bit of manipulation (this is a real pain, but once in Excel you will love it).

Edit the XML file in a text editor and delete the header lines that are the result of the web service function call, leaving just the raw XML:

Save the file and then it will happily open in Excel!

As mentioned, this is a snapshot of the work process table at the point when an issue occurred.
Very useful indeed.
You have lots of other XML files to examine.

Plus, as an added bonus, further down the directory structure of the snapshot zip file, is a complete XML snapshot of all the developer trace files for this app server:

How can we manually create SNAPSHOTS?

You can manually create and administer the snapshots (they will need clearing down) using the SAP instance agent (sapcontrol) web service commands as follows:

sapcontrol -nr <##> -function [snapshot_function]
  CreateSnapshot [<description> [<datcol_param> [<analyse_severity -1..2>
  [<analyse_maxentries> [<analyse_starttime YYYY MM DD HH:MM:SS>
  <analyse_endtime YYYY MM DD HH:MM:SS> [<maxentries>
  [<filename1> … <filenameN>]]]]]]]
  ReadSnapshot <filename> [<local filename>]
  DeleteSnapshots <filename1> [<filename2>… <filenameN>]

The ABAP transaction SNAPSHOTS only allows you to view/download and delete the snapshots. You can not trigger them using any standard transaction that I can find.

HANA 2.0 – Calc View – SAP DBTech JDBC 2048 Column Store Error

Scenario: During DB access of a HANA 2.0 SPS3 Calculation View from S/4HANA ABAP stack (via ABAP) or even directly in HANA Studio (via “Raw Data”), an error is displayed in a short dump or on screen along the lines of “SAP DBTech JDBC (2048: column store error: search table error: (nnnn) Instantiation of calculation model failed: exception 30600. An Internal error occurred”.

After investigation you observe the following error inside the indexserver trace log: “Could not get template scenario <SID>::_SYS_BIC:_SYS_SS_CE_<nnnn>_vers2_lang6_type1_CS_2_2_TMP (t -1) of calculation index <SID>::_SYS_BIC:<PACKAGE>/<CALCVIEW> (t -1). reason: CalculationEngine read from metadata failed.; Condition ‘aScenarioHandle.is_valid()’ failed.”.

The error clearly references the name of your Calculation View (calculation index) but it also references another object with a name like “_SYS_SS_CE_*”.

SAP note 1646743 explains that objects with a naming convention of “_SYS_SS_CE_<guid>_TMPTBL” are temporary tables created during compilation of procedure objects. Whilst our objects naming convention is not an exact match, the assumption is that the object is temporary in nature and created during the compilation of our Calculation View.

To backup the above theory, SAP note 2717365 matches the initial error message in some respects and shows the method to recompile the temporary object.
The note explains that to reproduce its described situation you must “Create a script calculation view which is created based on a procedure.”.

With this in mind, after checking our erroring Calculation View, it is clearly possible to see that ours utilises a “Script” as part of its design.

Therefore, we can assume that the temporary object with naming convention “_SYS_SS_CE_<nnnn>_vers2_lang6_type1_CS_2_2_TMP” is the temporary representation of the script from within our Calculation View.

Following the SAP note, we can recompile the object via its source Calculation View as follows using HANA Studio SQL execution (or hdbsql command line):

(NOTE: in our case the object is owned by user SAPABAP1, so we login/connect as that user in order to execute)


The execution succeeds.
However on retrying to access the data within the view, we still get an error.
What happened, well looking again at our Calculation View, it appears that it references another Calculation View!
So we must recompile all referencing Calculation Views also.

To cut a long story short, it turned out that we had over 4 levels Calculation Views before I decided to just recompile all procedures (if existing) of all known Calculation Views. Some of the views were even in different schemas.

How do we obtain a list of all Calculation Views that use a script and would have temporary procedures?

We can use this SQL string to create the required list of “type 6” objects:

SELECT ‘ALTER PROCEDURE “‘||schema||'”.”‘||name||'” RECOMPILE;’ FROM sys.p_objects_ WHERE type=6 and name like ‘%/proc’

How did I find this? All (or most) HANA objects are represented in the SYS.P_OBJECTS table.

Even temporary SQL objects need to be accounted for in the general administrative operations of the database, they need to be listed somewhere and have a corresponding object ID.
By executing the SQL as the SAPABAP1 user, we get output in a similar fashion as to that shown below, with the first line being a column header:




We can then simply execute the output SQL lines for each object to be recompiled.
On attempting access to the Calculation View, it now correctly returns data (or no data), and does not show an error message.

The next question is, why did we get this problem?

Looking back at SAP note 2717365 it says “This error happens because the temporary created objects were not cleared up properly when this happened with an error.”.
Remember that this is not an exact match for our error, but I think the explanation is good enough.

An error occurred during the creation of the temporary procedures that underpin our scripted Calculation Views.

We don’t know what the error or issue was, but subsequently recompiling those Calculation View temporary procedures fixes the issue.


Scenario: You’ve installed the SAP ABAP Tools in Eclipse and you’re trying to browse the catalog in a SAP Netweaver system.
You keep getting an error prompt which contains the error ACM_UNEXPECTED_VALUE.  Checking for SAP notes takes you down the path of ACLs and DCL for ABAP CDS views.  However, you’re not convinced this is the right direction to resolve your problem.

I had the above issue and it was a simple case of a large number of the ABAP CDS (Core Data Services) views in the database did not exist (they had either not been created or failed to activate). 

It was nothing to do with authorisations or permissions (I had profile SAP_ALL).
I was also seeing quite a number of short dumps related to “table not found” type errors from the database layer.

To fix the problem, SAP note 2519431 documents transaction SDDLAR (I was in a NW 7.52 system).

You can run transaction SDDLAR then select “All Missing DDL Views” in the section “Repair“; then click “Activate“.
It gives you the option of running with “Check Only“, without modification to the database.
Browse the list of returned objects that are missing, then when you’re ready, try and activate them all by re-running the report with the “Check and Repair” option selected.

SAP Solution Manager Central J2EE Monitor Bug

There is a small bug in the ABAP code when registering a SAP system to be monitored in a central system (e.g. Solution Manager) in transaction RZ21.
This was found on a Solution Manager 7.1 system.

The scenario is:
You try and register a remote monitor entry in RZ21, you enter the message server details of the system, the password for the CSMREG and the <sid>adm user, then click Save.  The screen gets to the “generating logical ports…” section but you notice that it mentions a non-existent instance number for the system it’s generating the ports for e.g. instance 00, instead of 01.
At the end of the process, you get an error about invalid XML or an XML error in the error message panel.

The reason:
If the SAP system to be monitored, has an instance which is using a HTTP port that is less than 3 digits (e.g. port 80), then the ABAP code in the Solution Manager, incorrectly determines the instance number of the instance to be “00”.

To get around the issue, the ABAP debugger had to be used to manually adjust the instance number prior to it being saved.

Create a breakpoint in the code as follows.
Use SE38 to display the source of include LSALWS_CONFIGF01:


Scroll to line 1276:


Click to add a new session breakpoint:



Then, before you click “Save” in RZ21 after entering the message server details and passwords, type “/h” into the command bar:


Then click Save in RZ21.
Once the breakpoint line is reached, the debugger will be launched and displayed.
Change the value for the variable “ws_instance_list-inst” from “00” to the correct instance values (in our case it was “01”), then continue the execution from the debugger: and the entries will be created correctly.

For systems with multiple instances, you need to change both instances during the loop so ensure that you do not remove the session breakpoint until the save process is completed.

If you have tried to register the system in RZ21 before, and it failed, there may be an invalid entry now present in the Topology view in RZ21.
Simply delete the invalid segment from RZ21.

Overview of Tasks for SAP NW731 System Copy – ABAP

Below is an overview of the tasks associated with an SAP NW731 system copy for ABAP on Windows with MS SQL Server (see the Java tasks here).  Essentially this is what I document when I go through the process:

  • Current Base Details – Current Kernel version etc.
  • Current Profile Files
  • Current ABAP License
  • Current SSL PSEs (export PSEs)
  • Current Transport Management System Config
  • Current Database Files
  • Source Database Files
  • Source Disk Usage
  • Target Disk Capacity
  • Current SQL Server Version
  • Current Windows Hotfixes
  • Download SWPM
  • Download Kernel 7.20 SWPM Install Media (UC + NUC)
  • Upload Required Media to Target Server
  • Identify Source Database Backup Media
  • Note Last Backups of Target Database
  • Shutdown Target SAP System
  • Snapshot of Server VM (or Full Server Backup)
  • Detach Old Target Database
  • Delete Old Database Files
  • Create Additional Data File Locations (that don’t exist in target)
  • Restore Database as Target
  • Rename Logical Files (MS SQL Server)
  • Deploy SWPM
  • Launch SWPM

Follow on in standard copy doc:

  • Apply Tasks in SAP Note 1817705
  • Truncate specific Tables
  • Check Installation
  • Stop Background Jobs
  • Remove RFC Connections
  • Lock and Adapt Printers & Spool Servers
  • Execute RSPO0041 to Remove Spool Requests
  • Execute RSBTCDEL2 to Remove Job Logs
  • Check Background Job Servers
  • Import Profiles (RZ10)
  • Check Operation Mode (RZ03)
  • Check Logon Groups (SMLG)
  • Check RFC Server Groups (RZ12)
  • Check tRFCs (SM58)
  • ReCreate PSE (STRUST)
  • Change Logical System Name (BDLS)
  • Check Custom External Commands (SM69)
  • Re-enable Background Jobs
  • Schedule Database Check (DB13)
  • Configure STMS
  • Database Stats Collection
  • Re-Install License Key
  • Migrate SecStore (SECSTORE)
  • Access SM21
  • Configure & Schedule Database Backup
  • Adjust Default Database Connection for <sid>adm User (MS SQL)
  • Release VM Snapshot (or send tapes offsite)