Problems with RFC data transfer between Unicode and non-Unicode systems

Step1: Preparation

The below given information is vital for analyzing the source of the problem:

a) Kernel patch and Support package level of the systems involved.
b) Short dump (provide complete content!), if available.
c) Direction of RFC data transfer (who calls (client), who is called (server)?):

- Unicode (client) ' non-Unicode (server)
or
- non-Unicode (client) ' Unicode (server)

If the direction is not obvious one can review the short dump to detect: It normally includes a section "Information about program making the Remote Function Call (RFC)" pointing to the client system and the used destination.

d) When the client initiates the call, what RFC destination is used?
e) Error messages in developer trace (ST11):

Reproduce the data transfer and review the developer trace files on the Unicode side (use ST11). Usually the uppermost dev_wN trace contains the relevant information (if there is a short dump available, N correspond the number of the work process given under system environment information). Search for entries comprising of function names starting with 'rscpL*' or 'readL*. Usually the entries look like follows:

"ERROR => RFC ====> rscpLangCPListGetCP failed (16): lang: X
"ERROR => RFC ====> rscpLangCPListGetCPtry failed (16): lang: X"
"ERROR => RFC ====> rscpLangCPListGetCPdst failed (16): lang: X"

The value 'lang:' (here = X) indicates the 1-letter language key of the transferred data.

More comprehensive RFC trace information can be attained by activating the extended NUS-US RFC Trace via report RSCP_RFCTRACE_SWITCH: On the Unicode system, by switching on the extended trace using this report and reproduce the data transfer again. Later the developer trace (also on the Unicode system) will include more detailed information. 647495, Appendix C contains a description how to use report RSCP_RFCTRACE_SWITCH, as well as instances explaining the meaning of the resulting trace entries.

If report RSCP_RFCTRACE_SWITCH is not yet available in the Unicode system, make the report ZSAP_RSCP_RFCTRACE_SWITCH via the preliminary version attached to 647495.
f) What would be the language configuration of the non-Unicode system?

Run report RSCP0018 (default settings) on the non-Unicode system. The output list includes the required information in sections 'TCP0I', 'TCPDB' and 'LOCALES'

Step 2: Analysis

Through the information derived from above, go through the paragraphs mentioned below.

Indications and related diagnosis are categorized and assembled in three levels:

Level 1:

- RFC CALL DIRECTION

Level 2:

- Error message from developer trace (rscpLang*)
 Release of non-Unicode system (if necessary)

 Level 3:

- Additional symptoms, Prerequisites, Diagnosis, Solution

I. RFC call direction from NON-UNICODE TO UNICODE (for the other direction see section II.):

I.1

"ERROR =>RFC====> rscpLangCPListGetCPtry failed (2048): lang: X"

Meaning: Language/Code page vector is NOT passed by the non-Unicode system and the given language (lang: X) is not assigned per default.

I.1.1 Non-Unicode as of Release 6.20
 
Additional symptoms

Short dump RFC_CONVERSION_STRUC or RFC_CONVERSION_TABLE takes place on the Unicode system, RFC aborts with an exception on non-Unicode system.

Prerequisites

The calling non-Unicode is a single CP system (section 'TCPDB' of RSCP0018-output has ONE entry only) and the kernel patch level is older than 620/1732 or 640/46.
The language/CP association differs from default (refer to point 1g) above) or data assigned to Z-languages are used.

Diagnosis:

Kernel error: for Single CP systems, the language/code page assignment provided by the non-Unicode system is not taken into account (Instead a default language/code page list is used and a default entry for lang:X does not exist).

Solution:

Apply the kernel patches indicated in SAP 790485.

I.1. 2 Non-Unicode system release 46C and older

I.1.2.1 

Additional Symptoms

Short dump RFC_CONVERSION_TABLE occurs on Unicode system
or:  Text data are corrupted

Diagnosis:

The actual language/ code page association of the client system differs from the default association (see Step 1.g) from above) applied. Thus, an incorrect code page is used for character conversion on Unicode side.

Solution: 

Follow the instructions in SAP 722193 and declare a Legacy RFC destination with the correct language/code page configuration of the client system.

I.1.2.2 

Additional Symptoms

rscpLang message in developer trace contains a Z-language (Z1-Z9), or any other language which is not part of the default language/code page list (e.g. language '1' on EBCDIC systems).

Example: "rscpLangCPListGetCPtry failed (16): lang: ( ".

Diagnosis: 

RFC uses a default language /code page list. This list does not cover any Z-languages.

Solution:

Refer to 871945.

Alternatively: Exclude those data from RFC data transfer.

I.1. 2.3 

Additional Symptoms

- rscpLang message contains lang: '  ' (sic, only space to the right of lang!)
- The Unicode system is at 6.20 kernel patch level <1659, 6.40 kernel patch level <38.
- Short dump RFC_CONVERSION_STRUC or RFC_CONVERSION_TABLE occurs on Unicode system.
- dev_rfcX traces on non-Unicode system contain messages like:'===> Parameter cannot be converted from characterset 1100 to 4102' (or similar code pages).

Alternatively: ' The 0 line of the table could not be converted' (or similar).
 
Solution:

Apply the kernel patches specified in SAP 722193, Appendix "Bug Fix for RFC_CONVERSION_STRUC when LANG=Space". The note also provides a test to verify if the patches really apply to your problem.

I.1.2.4 

Additional Symptoms:

- Short dump "CALL_FUNCTION_REMOTE_ERROR: 0 row of table cannot be converted" on non-Unicode system.
- Short dump "RFC_CONVERSION_TABLE: 0 row of table cannot be converted" on Unicode system.
- Extended NUS-US RFC Trace (647495, Appendix C) on Unicode system contains entries like:

readLClistA;3512: SAP_O_K 1401. list=A1401D$1100E$$ lang=`D'.
rscpLCgetCtry;3807: Legacy rc=0 `1401'; `H3I' `D' conCP=`1100'.

Diagnosis:

Indirectly, a language/code page list of a legacy RFC destination is used to replace the missing list from non-Unicode system. This list does not contain language 'X'.

Solution:

Refer to 722193 (section 'NOTE Implicit Activation) to detect the legacy destination. Deactivate 'MDMP Settings' or add language 'X' to the list of this destination.
Or: create an explicit Legacy RFC destination which automatically overrides all implicit destinations.
I.1. 2.5 

Additional Symptoms

- rscpLang message contains lang: ',' (sic, colon which refers to customer defined language Z4!)
- Extended NUS-US RFC Trace (note 647495, Appendix C) on Unicode system contains entries like:
 readLClistA;1262: RSCPENOCONV eror.
 list=A1100()-/7DEFIKNOPSUVai$84001$86002$$ lang=','.
- Legacy mode is active for the used destination (cf 722193) and the language/code page vector stored in the server's CCC for the client system contains language key "-", instead of "," (which is the correct internal representation of Z4).
- Exception SYSTEM_FAILURE on client side.

Diagnosis & Solution:
See 869322.
 
I.2 

"ERROR =>RFC====>rscpLangCPListGetCP failed (2048): lang: X"

Meaning: 

Non-Unicode Client is on Release 620 or younger and hence supplies its language/CP vector to the called UC system. But the vector does not contain language X.

Additional Symptoms
Short dump RFC_CONVERSION_TABLE on Unicode system

Diagnosis

Language X (from rscpLang* message) is an unknown and inactive language on the non-Unicode system. Thus, language X is not part of the language/CP list on the non-Unicode client.
(To confirm: Check the language vector sent by the client on the client side by listing the CCC statistics: Trx SNLS, menu 'CodePages -> CCC'. The section 'RFC condensed list' shows a sequence of code pages followed by the assigned languages (as 1-letter codes).

Example:

1100.DE1401.C

This implies that EN and DE are assigned to 1100, CS is assigned to 1401).

Solution:

Apply SAP 920831.
Alternatively: Activate the unknown languages on the non-Unicode system with report RCPINST or remove / exclude data with unknown language keys.
II. RFC call direction from UNICODE TO NON-UNICODE:
GENERAL INFORMATION
The language/codepage assignment (MDMP settings active) for the used RFC destination should be manually configured (MDMP settings active) for the direction Unicode to non-Unicode. Read 547444 to understand how to do that.
If the manual configuration is not found (i.e. the destination is configured as 'MDMP inactive'), a default assignment can be used. This works quite easily for most language constellation, but not for e.g. customer defined Z-languages (Z1-Z9), or languages which are not in alignment with the default codepage assignment (e.g. EN in non-Latin1 Single codepage configurations).
II.1 
"ERROR =>RFC====> rscpLangCPListGetCPdst failed (2048): lang: X"
Meaning: 
Outgoing call through a destination with 'MDMP settings' set to 'Active' in SM59 on Unicode side. The manually configured language/code page list from the RFC destination is used and the assignment for language X is missing.
II.1.1 
Additional Symptoms:
Short dump RFC_CONVERSION_STRUC or RFC_CONVERSION_TABLE on Unicode system
Diagnosis
The language/code page list of the RFC destination is incomplete in respect of the data to be transferred.
Solution:
Finish the language/code page list for the destination in SM59, as explained in SAP 647495, section 'Entering MDMP Destination System Information'. Add language X to the list.
II.1. 2 
Additional Symptoms:
Short dump CALL_FUNCTION_OPEN_ERROR or CALL_FUNCTION_REMOTE_ERROR on client side
Diagnosis
The language/code page list from the RFC destination is not completed in respect of the data to be transferred.
In this case, usually customer-defined languages (Z1-Z9) are included.
Solution:
Complete the language/code page list for the destination in SM59, as explained in SAP 647495, section 'Entering MDMP Destination System Information'. Add language X to the list.
II.1. 3 
Special case:
Bug in Kernel 640, patch level 31-34.
 Solution:
Kernel 640, patch level 35 (SAP 647495 (S9)).
II.1. 4 
Additional Symptoms:
- rscpLang message contains lang: ',' (sic, colon which refers to customer defined language Z4!).
- The Codepage Maintenance list of the call destination contains language Z4.
- Exception COMMUNICATION_FAILURE on client side.
Diagnosis & Solution
See 869322
II.2 
"ERROR =>RFC====> rscpLangCPListGetCPtry failed (2048): lang: X"
Meaning: 
Outgoing call through a destination with 'MDMP settings' set to 'Inactive' on Unicode side. Thus, default codepages are used, and language 'X' has no default code page assignment. Usually this happens for customer defined languages (Z1-Z9).
II.2. 1 
Additional Symptoms:
Short dump CALL_FUNCTION_OPEN_ERROR on Unicode system
Diagnosis:
A language which is not part of the SAP default code page assignment (e.g. a Z-language) is involved.
Solution:
Activate 'MDMP settings' for the destination in SM59 and maintain the language/code page list, as explained in SAP 647495, section 'Entering MDMP Destination System Information'.  Add language X to the list.
II.2. 2 
Special case:
Short dump CALL_FUNCTION_OPEN_ERROR on Unicode system, although MDMP settings are active for the used destination and 'lang: X' is maintained properly.
The kernel patch level is older than:
620: 1864
640: 65
700: 5
Diagnosis
Kernel error: The code page/language assignment list maintained in SM59 (as explained above) is ignored in tRFC. See SAP 827999(component BC-MID-RFC) for details.
Solution
Implement the kernel patches indicated in 828000.
 
II.3 
No "rscpLang*" error message in developer trace
II.3. 1
Additional Symptoms:
Short dump RFC_CONVERSION_FIELD in function 'ab_rfcImplode' on Unicode system: 'Conversion error "ab_rfccon" from character set 4102 to character set 1100.'
Diagnosis
Error converting outgoing data from Unicode (4102 or 4103) to non-Unicode (1100 or any other non-Unicode code page number): The Unicode data contain characters which cannot be represented by the given non-Unicode code page.
Solution:
See 647495: "Section D: Unconvertible Data in RFC between MDMP and Unicode Systems"
II.3. 2 
Additional Symptoms:
Data contain "#" upon arrival in the non-Unicode system.
INSTANCE: the Unicode system sends Asian character associated with language English; because of default settings of the RFC destination (cf 647495, App A) these are changed to code page 1100 (Latin-1, west European) and are substituted by "#" because this conversion fails (correctly).
Diagnosis
Character transformation from Unicode to non-Unicode gets wrong non-Unicode destination encoding, and replaces characters (wrongly) considered to be unconvertible by the replacement character.
Solution
Set the MDMP destination to "MDMP active", and assign the correct code page to the language in question.
INSTANCE: In the above instance, assign the appropriate non-Unicode code page, e.g. 8000 for Japanese characters, to English.

For general information on how to handle RFC connections between Unicode and non-Unicode, please refer to Knowledge Warehouse (Menu 'Help -> SAP Library'):
SAP Netweaver -> Application Platform (SAP Web AS) -> ABAP Technology -> ABAP Programming and Runtime Environment (BC-ABA) -> External Programming Interfaces -> RFC Programming in ABAP -> Calling Remote Function Modules in ABAP: 'Characteristics Using Unicode'
SAP Netweaver -> Application Platform (SAP Web AS) -> ABAP Technology -> ABAP Programming and Runtime Environment (BC-ABA) -> External Programming Interfaces -> RFC Programming in ABAP -> Maintaining Remote Destinations: 'Settings for Special Code Pages'