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

Network Port Test Using SAP NIPING

Some companies have additional security policies that remove the Telnet application from the local desktop PCs.
This can prove difficult for SAP BASIS people trying to test if a specific network port is reachable, since Telnet is a perfect way of testing if a server port is accessible, or being blocked by a firewall.
Instead, you can use the NIPING tool (Network Interface Ping) supplied with the SAP Frontend installation on the desktop PC.

Check if you have NIPING.exe, it should exist in the default install location: “C:Program FilesSAPFrontEndSAPgui”.

You have to call NIPING from a command prompt:

C:> cd C:Program FilesSAPFrontEndSAPgui

There are two command line options that are useful when calling NIPING.
The command line option “-R” tells NIPING to attempt a RAW TCP connection.
Option “-P” specifies that NIPING should option slightly more detail.

If you need to test if a network port is available, you need to use the RAW option.
You don’t care what transport layer protocol is required (SMTP, HTTP, Telnet, SSH), you just want it to try and open a bare TCP connection to the specified port and see what happens.

To use NIPING with the RAW option:

> niping -c -H <dest host>  -S <dest port>  -R  -P

You will get some fairly detailed output.
What you are looking for is a return code (RC) of “-6” and “ERROR connection to partner ‘xxx.xxx.xxx.xxx:pppp’ broken“.

The RC of “-6” indicates that NIPING was able to open the TCP connection (NIPCONNECT) successfully, but it was not able to receive (NILREAD)  because the server closed the connection when we didn’t send any information (it was a raw connection).

If you receive an RC of “-10” and “ERROR partner xxx.xxx.xxx.xxx:pppp not reached” this indicates that NIPING was not able to even establish a basic TCP connection (NIPCONNECT) to the server host and port.
You may not have an network route to the server, the server IP may be invalid, the port may not be listening on the server, a firewall may be blocking you and many other reasons.

If you are simply trying to connect to a known SAP system dispatcher port (for SAP GUI connections), then using NIPING without the RAW option will perform an RFC connection to the SAP system dispatcher, if possible:

> niping -c -H <dest host>  -S 32<SAP_sys_id>

When you use NIPING without the RAW option, it will return success (“Connect to server o.k.“) if it can successfully connect to the SAP system dispatcher.  It will always complain about “bytes_written <> bytes_read“, so ignore this error.

You should note that connecting to the SAP ABAP message server (36xx) will return a “ERROR connection to partner xxx.xxx.xxx.xxx:pppp broken” and RC “-6” (just like a RAW connection) if it was successful.
The reason is that this is not a straight RFC connection that supports NIPING.  It’s meant to hand-off to a specific dispatcher or other tasks, but not ping.

SAP R3load Error TOC is Not From Same Export

During an R3load import process, you are importing the data files generated from a successful R3load export.
However, you are seeing errors in the <PACKAGE>.log file along the lines of:
(DB) INFO: connected to DB
(DB) INFO: DbSlControl(DBSL_CMD_NLS_CHARACTERSET_GET): UTF16
(RFF) ERROR: <PACKAGE>.TOC is not from the same export as <PACKAGE>.001

This occurs when the TOC (table of contents) file is corrupt.
The TOC file is generated during the export process and contains the name(s) of the tables in the export package and the number of records inside the relevant data files (files ending with .nnn   e.g. .001).
The corruption can happen if you terminated an export, or an export failed (maybe because of disk space), and you then restarted the export (either through the SUM, SAPInst or by manually editing the .properties file).
If you failed to remove the already generated .TOC file for the failed package, before restarting the export, then the .TOC file will be confused and think that the subsequent export, is an append operation to the existing data file.
A normal .TOC file should have something like:

vn: R7.20/V1.6
id: de1a50a500000043
cp: 4102
data_with_checksum
tab: [HEADER]
fil: <PACKAGE>.001 1024
1 1
eot: #0 rows 20130902160509
tab: <TABLE>
fil: <PACKAGE>.001 1024
2 1024000
eot: #50212404 rows 20130902184553

eof: #20130902184553

A corrupt .TOC file for the same package, would look something like:

vn: R7.20/V1.6
id: de1a50a500000043
cp: 4102
data_with_checksum
tab: [HEADER]
fil: <PACKAGE>.001 1024
1 1
eot: #0 rows 20130902160509
tab: <TABLE>
fil: <PACKAGE>.001 1024
2 1024000
eot: #50212404 rows 20130902184553
tab: <TABLE>
fil: <PACKAGE>.001 1024
1024001 2048000

eot: #50212404 rows 20130903161923

eof: #20130903161923
Notice the additional four lines generated in the file during a second export attempt.
This would cause the import to fail.
It’s not possible to adjust the .TOC file manually, as it seems that the .TOC file and the data files are tied with a checksum somehow.
The only time you will find out that the export .TOC files are corrupt, is when you try to import them.  Maybe SAP could write a verification routine into the R3load program.

Checking R3load Export Progress

When running R3load to export an Oracle SAP database, it’s difficult to see the exact table or tables that is/are being exported.

You can log into the Oracle database during the R3load execution and use the following SQL to follow the progress:
SQL> select sess.process, sql.sql_text
       from v$session sess,
            v$sqltext sql
      where sess.type='USER'
        and sess.module like 'DBSL%'
        and sql.sql_text like '%FROM%'
      order by sql.part;

This will show the OS process ID of the R3load process, plus the table (from the FROM clause)  that is currently being exported.
For large tables, you may be able to see the progress in the V$SESSION_LONGOPS table by looking for rows where TOTALWORK != SOFAR.

SAP Kernel librfcum.so Missing

When trying to start a SAP system I got an error from the sapstart.log indicating that librfcum.so was missing.
This was not in any of the exe directories or in any of the Kernel distribution files.

During an upgrade, a kernel was patched with a unicode kernel when it should have been a non-unicode kernel.
The correct kernel patch was then deployed into the central exe directory, but it looks like sapcpe did not correctly detect and replace the kernel files on the other instances.

The solution to the missing librfcum.so problem, was to completely remove the kernel files in the instance exe directories, then manually run sapcpe (sapcpe pf=<instance pf>) to re-copy the files from the central exe directory.

This fixed the issue.

SAP R3load table splitter – Table Analysis Performance

Be careful when using the R3load table splitter from the Software Provisioning Manager screens.
You are asked to supply your table split file, in the install guide, in the format “<TABLE>%<# SPLITS>”.
However, this does not supply the table column to split by.

When splitting large tables, during the Table Splitting preparation phase (before you even start exports), R3ta can run for quite a while whilst is performs scans of the available INDEXES and then COUNTs the number of rows in the table(s) to be split.

It’s trying to define the most apt column(s) to use for generating the WHR files which contain the query predicates.

I tried adding a specific column during the initial table splitter screens, where you can specify the column to use. However, this seems to be completely ignored.

The best advice, is to prepare your table split during your proof phase in the sandbox environment, then potentially manually adjust the final WHR file to account for any additional rows in the table(s) to be split.
This will save a lot of time and effort in the true production conversion run.
Also, ensure that the indexes on those tables, especially the ones that the WHR predicates refer to, are rebuilt if possible.