Page tree
Skip to end of metadata
Go to start of metadata


This release introduces support for CDS objects (affects R3load and R3ldctl). New features are available with the next patch level in kernel releases 7.40, 7.41 and 7.42. All patches are available in the same releases. Additionally patch 8 is implemented in 7.20 and 7.21 releases.

Current release includes following corrections:

1. R3load breaks with "malloc() memory corruption" error if task file (tsk) contains "cnt:" token.

"cnt:" token is written by DMO fast splitting tool. After this fix R3load correctly skips this field when it parses the task file.

2. R3load stops and writes an error message if called with the wrong dbms_type environment (e.g. Sybase R3load in the Oracle environment).

Previous behavior was to continue execution, which could cause the problem, if the customer mistakenly updated the kernel with the wrong R3load.

3. R3load supports pipe and socket mode with buffer size up to 2Gb.

R3load supported previously buffer size up to 100Mb because of 8 digit number used to determine the size of the block in the socket or pipe protocol. Current implementation uses 10 digits, increasing corresponsindly supported buffer size up to 2Gb. Additional checks were implemented to fail gracefully if larger buffer size is used.

4. R3load while importing tables stops in pipe migration mode (DMO) stops with the error message:

unexpected message "00000000 00000000END OF JOB"

This error happens if empty tables are transferred over the pipe connection.

5. R3load in declustering mode may ignore errors in create primary key, index, view, table tasks and continue execution of tasks

Currently in declustering mode R3load ignores errors during execution of DB object manipulation tasks ('P', 'T', 'I', 'V'). After the fix, R3load correctly reports an error and stops processing the list of tasks.

6. Import is stuck or aborts with a core dump in pipe mode when processing tables with LOB objects larger than 100Mb (DMO scenario).

Importing R3load may get stuck or abort with a core dump, when processed table has LOB objects larger than 100Mb. Depending on the platform importing R3load process may hang consuming 100% CPU or immediately abort with a core dump. As a work-around, you can use file mode instead of pipe mode (set parameter "method=file" in the DMO configuration file). The fix requires an update of R3load executable in both kernel directories (source AnyDB in <SUMDIR>/exe and target HANA in <SUMDIR>/exe_2nd).

7. Improve import speed of DYNPSOURCE, REPOSRC, pool tables in declustering scenarios (SWPM system copy to HANA, DMO) and avoid false positives in the Table Checker Tool (SUM). 

R3load performed unnecessary compression and decompression of tables REPOSRC; REPOTEXT, DYNPSOURCE, DDNTF, DDNTT as well as pool tables if called in declustering mode (command line option -decluster). Besides of performance penalty, this bug caused false positives in the Table Checker tool.  The recompressed BLOB fields with text were not binary identical to the original content. The data was not really damaged, because the uncompressed content of those tables, as seen by ABAP application server, is identical to the original content. The binary difference of the recompressed content is caused by the implementation of compression algorithm.

8. R3load fetches incorrect ranges on SAP ASE database if binary field is used as split condition.

R3load uses an SQL'92 standard format to encode literals for binary data in where conditions in task and WHR files (e.g. x‘0123456789abcdef‘). SAP ASE uses a different syntax for definition of literals for binary data (e.g. 0x0123456789abcdef). Generated exports files therefore contain data which is packaged incorrectly or the export fails with a syntax error. This results in slower export/import and checksum errors at import during system copy (SWPM) of system migration to HANA (DMO) if the following conditions are met:

1. Source database is SAP ASE.

2. Table splitting is active.

3. Table fields of type RAW are used in the split condition (e.g. "GUID").

The current fix makes sure that literals for binary data in the select condition is adapted from SQL'92 to SAP ASE specific format before sending them to database server.

9. Format long "negdat" values in DDLHDB.TPL in multiple lines (R3load for HANA).

Overly long "negdat" lines in DDLHDB.TPL have been breaking SAPup in DMO scenario. This change makes R3load start the new line to form a nicely formatted text block if the size "negdat" value exceeds a 20 characters. Independently SAPup was also fixed to support long lines.



See note 1981718 - R3load: support for CDS views and some fixes

  • No labels