Unicode conversion, blended codepages etc

Hello.
We have a ERP 6.0 single-codepage system on Windows/Oracle.
The current system codepage is ISO8859-1 (SAP Codepage 1100), which is fine cause we currently only use Latin-1 languages.
However a new project implementation requires installation of Polish language (ISO8859-2)(SAP Codepage 1401).
As i see it we have three choices: MDMP, SAP blended codepage 6100 or Unicode conversion.
Obviously we wish to follow SAP's recommendations and do a unicode conversion, but i would like some feedback on whether my assumptions are correct ?
Thank you in advance.
Gerhard.

Yes, they are.
MDMP is a proprietary technology that uses the user context and the logon language herein to determine the codepage. It has limitations but it was the only way for systems before Unicode.
A single codepage system conversion to Unicode is pretty straightforward, I'd do that BEFORE you install Polish (or any other non-Latin-1 language).
Markus

Similar Messages

Expertise Advices on ASSM + Unicode Conversion

Hi,
I need some Expertise advice on Converting oracle Table Space to ASSM and Unicode.
Our company planning on upgrading ECC 5.0 to ECC 6.0 then we also want to do Unicode migration, but we need to know; what/when are the best practices to convert the oracle tablespace to ASSM?
I believe part of Unicode migrations we have to convert the Oracle tablespace to ASSM.
Option 1:
Is it better to convert all the tablespaces to ASSM before we do a Unicode migration? And then do the Unicode migrations?
Option 2:
Or is it better to do everything together at the same time Unicode Migrations and Tablespace conversation?
Is there are any benefits between those two options? Which one is really time saving? Option 1 or Option 2
Quick question on the side, how long would it take to convert 450 GB total data to ASSM?
Please advice on this!
Thanks in Advances
Kumar

I would suggest the following: Forget about ASSM - it will be enabled by default after your conversion, that's all I can say about ASSM in this context.
The Unicode migration itself is a really complex process, we had quite some issue to fight with. To see the whole story we were going through read that thread:
combined upgrade and unicode conversion
The topic is a bit different but I explain in-depth there, what problems we encountered, maybe this will helpful for you too.
You're right, the guides are pretty complex and the procedure and preparation is too so I would NOT do that as newbie (no offense). We had a consultant from SAP on-site while we were doing the preparation for the migration because of those many languages we had. The migration itself was then done by me after those four tests migrations I mentioned earlier.
If your system is a single codepage migration, it's not that difficult if you follow the guides provided (http://service.sap.com/unicode@sap) for your specific support package level. Just follow it step-by-step, read all the note (yes, I know, there are SO MANY).
My "best practice recommendations" are:
- use the VERY LATEST tools (kernel, R3load and dboraslib) for the export (VERY important!)
- if possible, install the latest Basis support package (SP 12 in your case) <b>before</b> you start the preparation (that is running the task of SPUMG)
- If you install the unicode instance, also use the latest tools there, latest kernel and latest R3load, you can patch the system while the database is created (there's enough time)
- if you have external systems connected, make sure, they are aware of the fact, that they are "talking" to Unicode systems after the migration (Fax-Servers, EDI and also all SAP systems such as BW, CRM, SCM or also SAP-KPRO-Servers or what else you have there)
- test, test, test, don't do the migration just theoretically
I can't provide a guide, they are highly individual depending on what modules are implemented, what external interfaces and connections to systems you have etc. etc. I could provide you with a "guide" but I'm VERY sure, there's something missing/too much and I won't be responsible for any errors/problems you will get. We did a full day of just evaluating the system, interfaces etc.
The only advise is - do a test migration, connect the system to everything you also have on production and test.
Markus

Preparing for upgrade and Unicode conversion while on 4.6c

We're currently on 4.6c and preparing to upgrade to ERP 2005 and do a Unicode conversion. I'm trying to compile a list of coding techniques that can used in 4.6c that will minimize changes needed for Unicode. Does anyone have such a list?
Some things I've discovered reading about Unicode include:
1) Use GUI_UPLOAD and GUI_DOWNLOAD rather than WS_UPLOAD and WS_DOWNLOAD.
2) Structures or table headers that contain non-character data need to be identical when moving, comparing, selecting into, updating from, etc. This includes not moving structures/tables with non-character data to a character field or vice-versa.
3) Offsets can't cross non-character data.
4) Assign statement with offset must specify a length.
5) Open dataset must specify "FOR INPUT", "FOR OUTPUT", "FOR APPENDING", or "FOR UPDATE". It no longer defaults to FOR INPUT when omitted.
6) Many implicit conversions from char to numeric are no longer allowed. Use explicit conversion instead; such as the move statement.
I know there are others. Any help would be appreciated.
Regards,
Mark Perrey

Hai Mark
Check the following F.M Replacents
Upgrade Error Details     Suggestions
Function Module "DOCUMENT_REGISTRY_PROGRAM"not found in the target system     Suggest to replace this FM with the function module CV120_GET_APPL_FROM_REGISTRY.
Function Module "RP_HIRE+FIRE"not found in the target system     Suggest to replace this FM with the function module RP_HIRE_FIRE .
Function Module "ME_READ_HEADER_SINGLE" not found in the target system     Suggest to replace this FM with the function module ME_EKKO_SINGLE_READ.
Function Module "ME_READ_ITEM_SINGLE" not found in the target system     Suggest to replace this FM with the function module ME_EKPO_SINGLE_READ.
Function Module "RZL_ALERT_CONTROL" not found in the target system     Function Module "RZL_ALERT_CONTROL" is not available in the Enterprise Version. Suggest to use the function module "TH_SEND_ADM_MESS" to acheive the same functionality of "RZL_ALERT_CONTROL".
Function Module "MM_SELECT_ADDRESS" not found in the target system     Suggest to replace this FM with the function module MM_SELECT_PARTNER.
Function Module "MM_READ_ADDRESS" not found in the target system     Suggest to replace this FM with the function module MM_PARTNERS_FOR_MESSAGING
Function Module "ME_VALUES_T161" not found in the target system     Suggest to replace this FM with the function module HELP_VALUES_BSART.
Function Module "ME_VALUES_T024W" not found in the target system     . Suggest to replace this FM with the function module HELP_VALUES_WERKS.
Function Module "SD_PACKING_REFRESH" not found in the target system     Suggest to replace this FM with the function module HU_PACKING_REFRESH.
Function Module "SD_PACKING_RENAME" not found in the target system      Suggest to replace this FM with the function module V51P_PACKING_RENAME.
Function Module "RV_EXPORT_CONTROL_UPDATE" not found in the target system     Suggest to replace this FM with the function module RV_EXPORT_CONTROL_UPD_PREPARE.
Function Module "RV_INVOICE_COPY" not found in the target system     Suggest to replace this FM with the function module RV_SALES_DOCUMENT_COPY.
Function Module "SD_SCHEDULE_AGREEMENT_PACKING" not found in the target system     Suggest to replace this FM with the function module HU_PACKING_SALES_PROPOSAL.
Function Module "SERIAL_RENUM_WV" not found in the target system     Suggest to replace this FM with the function module IWOL_WV_SWITCH_NUMBER.
Function Module "CUD0_DISPLAY_CONFIGURATION" not found in the target system     Suggest to replace this FM with the function module VC_I_DISPLAY_CONFIGURATION.
Function Module "SD_PACKING_CREATE" not found in the target system     Suggest to replace this FM with the function module V51F_PACKING_CREATE.
Function Module "FI_ARCHIVE_CHECK_DOC" not found in the target system     Function Module FI_ARCHIVE_CHECK_DOC is not available in the Enterprise Version. Suggest to replace this FM with the function module FI_DOCUMENT_ARCH_CHECK_DOCS.
Function Module "OPEN_FI_CHECK" not found in the target system     Function Module OPEN_FI_CHECK is not available in the Enterprise Version. Suggest to replace this FM with the function module OPEN_FI_PERFORM_******_E.
Function Module "SD_PACKING_UPDATE"not found in the target system     Function Module SD_PACKING_UPDATE is not available in the Enterprise Version. Suggest to replace this FM with the function module HU_PACKING_UPDATE.
Function Module "F4_MACO" is being used in the program     Function Module "F4_MACO" is not available in the Enterprise Version. Since the Matchcode objects are not used in the Enterprise Version, Suggest to replace this FM with Search help's Value Request function module F4_SEARCH_HELP.
Function Module "SWZ_AI_RELEASE_S" is used in the program     Suggest to use the function module "SWZ_AI_RELEASE" instead of "SWZ_AI_RELEASE_S".
Function Module "SWW_WI_ORGTASK_READ" is used in the program      Suggest to replace this FM with the function module RH_WI_ORGTASK_READ.
Function Module "RH_READ_EXCEL_PATH" is being used in the program     Suggest to replace this FM with "RH_CHECK_EXCEL_SUPPORT".
Function Module "RZL_ALERT_CONTROL" is used in the program     Function Module "RZL_ALERT_CONTROL" is not available in the Enterprise Version. Suggest to use the function module "TH_SEND_ADM_MESS" to acheive the same functionality of "RZL_ALERT_CONTROL".
Function Module "CONVERT_TO_OTHER_CURRENCY" is used in the program     Suggest to ruse the function module "CONVERT_TO_LOCAL_CURRENCY" for currency conversion.
Function Module "LOAN_TABLECONTROL_SCROLLING" is not available in the Enterprise Version.      Suggest to replace this FM with the function module SCROLLING_IN_TABLE.
CALL FUNCTION 'DOWNLOAD' used in program is obsolete in target system.     "DOWNLOAD function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the unicode enabled methods
FILE_SAVE_DIALOG and GUI_DOWNLOAD
from class CL_GUI_FRONTEND_SERVICES.
Note:
However, to support existing applications, a compatibility mode was added to the function module(enhanced with Support Package) that will forward calls to DOWNLOAD to the new GUI_DOWNLOAD functions."
CALL FUNCTION 'HELP_VALUES_GET_NO_DD_NAME' used in program is obsolete in target system.     "HELP_VALUES_GET_NO_DD_NAME function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the function module F4IF_INT_TABLE_VALUE_REQUEST in the target system."
CALL FUNCTION 'POPUP_TO_CONFIRM_LOSS_OF_DATA' used in program is obsolete in target system.     "POPUP_TO_CONFIRM_LOSS_OF_DATA is obsolete in the target system.
Suggest to use function module POPUP_TO_CONFIRM."
CALL FUNCTION 'POPUP_TO_CONFIRM_STEP' used in program is obsolete in target system.     "POPUP_TO_CONFIRM_STEP is obsolete in the target system.
Suggest to use function module POPUP_TO_CONFIRM."
CALL FUNCTION 'WS_DOWNLOAD' used in program is obsolete in target system.     "WS_DOWNLOAD function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the unicode enabled GUI_DOWNLOAD function module.
Note:
However, to support existing applications, a compatibility mode was added to the function module(enhanced with Support Package) that will forward calls to WS_DOWNLOAD to the new GUI_DOWNLOAD function."
CALL FUNCTION 'WS_FILENAME_GET' used in program is obsolete in target system.     "WS_FILENAME_GET function module is obsolete, and results in errors on Unicode systems.
Suggest to use FILE_OPEN_DIALOG und FILE_SAVE_DIALOG Unicode-enabled methods of the cl_gui_frontend_services class.
Note:
New applications should restart on these methods instead of the function module. The function module is extended by a Support Package so that it diverts calls to the methods without the application having to be changed."
CALL FUNCTION 'WS_UPLOAD' used in program is obsolete in target system.     "WS_UPLOAD function module is obsolete and result in errors on Unicode systems or on systems that may potentially be Unicode enabled.
Suggest to use the unicode enabled GUI_UPLOAD function module.
Note:
However, to support existing applications, a compatibility mode was added to the function module(enhanced with Support Package) that will forward calls to WS_UPLOAD to the new GUI_UPLOAD function."
Function parameters EBENE, GRUPP, DATE_LOW, DATE_HIGH, BANKK. BUKRS, S_BUKRS, S_DISPW in function module CASH_FORECAST_TR_SELECT_ITEM is missing in the target system.     "Function Module CASH_FORECAST_TR_SELECT_ITEM is no longer used, instead it has been split based on the functionalities.
Suggest to use function module
1) CASH_FORECAST_PR_SELECT_ITEM for Payment Arrangements.
2) For TR, WP, DA use function module CASH_FORECAST_TR_ITEM_2.
The IMPORT and TABLES parameters of the above 2 function modules are almost same as CASH_FORECAST_TR_SELECT_ITEM.
The IMPORT parameter BUKRS is not available in the above 2 function modules. Hence suggest to change the coding accordingly."
Import parameter BUKRS in function CASH_FORECAST_LO_SELECT_ITEM is missing in the target system.     "Import parameter BUKRS in function CASH_FORECAST_LO_SELECT_ITEM is not available in the target system.
Also the coding in Function Module based on the parameter BUKRS has been removed, instead the TABLES parameter S_BUKRS and S_GSBER has been used.
Suggest to check the coding in the program accordingly.
Import parameter BUKRS in function CASH_FORECAST_RE_SELECT_ITEM is missing in the target system.     "Import parameter BUKRS in function CASH_FORECAST_RE_SELECT_ITEM is not available in the target system.
Also the coding in Function Module based on the parameter BUKRS has been removed, instead the TABLES parameter S_BUKRS and S_GSBER(new parameter) has been used.
Suggest to check the coding in the program accordingly.
Function Module HELP_VALUES_GET_WITH_MACO is obsolete in target system     Suggest to use F4IF_FIELD_VALUE_REQUEST
Function Module G_OBJECT_GET is obsolete in target system.     Suggest to Use G_INTERVAL_GET_NEXT
Function Module READ_COSTCENTER is obsolete in target system     Suggest to Use K_COSTCENTER_SELECT_SINGLE
Function Module K_BUSINESS_PROCESS_READ_MULTI is obsolete or not available in target system     Suggest to Use K_PROCESSES_SELECT_TAB
G_SET_AVAILABLE     Suggest to Use G_SET_GET_INFO
Function Module G_SET_DOUBLE_CHECK is obsolete or not available in target system     "DO NOT CALL THIS FUNCTION MODULE
FROM 4.0A VERSION ,THIS PROBLEM WILL NOT OCCUR"
Function Module HELP_VALUES_GET is obsolete or not available in target system     Suggest to Use F4IF_FIELD_VALUE_REQUEST
G_SELECT_SET     Suggest to Use G_SET_SELECT
Function Module G_SET_AVAILABLE is obsolete or not available in target system     Suggest to Use G_SET_GET_INFO
Function Module NAMETAB_GET is obsolete or not available in target system     Suggest to Use DDIF_FIELDINFO_GET
Function Module DD_GET_DD03P is obsolete or not available in target system     Suggest to Use DDIF_FIELDINFO_GET / DDIF_TABL_GET
CALL FUNCTION 'POPUP_TO_CONFIRM_WITH_MESSAGE' used in program is obsolete in target system.     Suggest to use function module POPUP_TO_CONFIRM.
CALL FUNCTION 'POPUP_TO_DECIDE' used in program is obsolete in target system.     Suggest to use function module POPUP_TO_CONFIRM.
Function Module HELP_VALUES_GET_WITH_TABLE is obsolete or not available in target system     Suggest to Use F4TOOL_F4FUNCTION_BRIDGE
Function Module CLPB_EXPORT is obsolete or not available in target system     "Suggest to Use Suggest to use the unicode enabled methods
CLIPBOARD_EXPORT from class CL_GUI_FRONTEND_SERVICES."
Function Module SAP_TO_ISO_MEASURE_UNIT_CODE is obsolete or not available in target system     Suggest to Use UNIT_OF_MEASURE_SAP_TO_ISO
Regards
Sreeni

MDMP Unicode Conversion problem during ECC upgrade

hi Experts,
I met a problem when upgrade from 4.6c to ecc 6.
in 4.6c, some key users made some chinese written entries in table field while he/she was logon as English, so, the language field in this entry is "EN" although the actual language was written by chinese, after upgrade to ECC6, we found the chinese words became messy code, maybe it was due to the chinese were encoded by english codepage during conversion, my question is, how can I avoid this? I really don't want this happen in our PRD upgrade.
The second question is: if a field contains both chinese and english, then, which language should it be assigned? english or chinese? I'm afraid if we assign this word as "EN" in vocabulary, then, after upgrade, the chinese part will be messy code.
Thank you for your kind suggestions.
Freshman

Hi,
you can either use transaction SUMG (manually) to repair the entries ( you have to add the according table - please check unicode conversion guide for details) or you need to change the language key in the table to Chinese if you want the Unicode conversion to convert the data correctly.
To your second question: If the English texts are restricted to US7ASCII characters ("normal" English without special characters) those texts containing Chinese and English words can (and must !) be assigned to ZH, as US7ASCII characters are included in the Chinese code page.
Best regards,
Nilsn Buerckel

Unicode conversion with MDMP, Errors in various TC´s SAINT , SNOTE,

Hallo All,
We perform CU&UC of R/3 4.6C sandbox system to the ERP 6.0 EHP5.
Currently the upgrade phase is completed and Unicode conversion should
be started (we are in the step "Additional Preparation Steps in NW 7.02
non-UC" in the CU&UC guide).
In various transactions (PFCG - Generating of profiles, SPAM/SAINT ) we
received an error "SAP characters 00367 and 00065 are not unique in
character set 1180". As a workaround we temporarily deleted Polish
language (PL) in program RSCPINST and activated (so only codepage 1100
was active). Currently we have activated the Polish language again.
In the source 4.6C system TMB (created by System Copy from productive
system PMB) there was also the configuration in RSCPINST of more than 1
codepage (1100, 1401) and in TCPDB table 1180 codepage was configured
(see attached pictures).
Our question :
How is it possible to avoid this situation in upgrades of following
system (IMB, QMB, PMB)? Could this configuration cause any
problems/inconsistencies during/after Unicode conversion export &
import ?
Regards Peter Gauer

Hello Nils,
After upgrade, before unicode conversion we got the following error message in PFCG, SAINT,..
"SAP characters 00367 and 00065 are not unique in character set 1180"
I got the information from T-Systems that they excluded polish languages out of RSCINST,
then codepage 1100 was used, than T-Systems added polish language again to have the original situation.
First message I got with the simulation (choose blank latin-1)
The required language combination is supported
only in Unicode systems
Please refer to SAP Note 73606.
Now I Choose: 4EU, EuropTranslit
and simulation showed no message above, but went to the next page.
see below
S e l e c t e d   S e t t i n g s :
Language(s):
EN (E) English
FR (F) French
DE (D) German
PL (L) Polish
ES (S) Spanish
Country code:
4EU    EuropTranslit
R e s u l t s :
Code page configuration type:
Non-Unicode - Single Code Page configuration
Processed language entry:
DEFLS
Language(s) and Corresponding Code Page(s):
EN (E) 1180   Transliteration from Latin-2 (...) to Latin-1
FR (F) 1180   Transliteration from Latin-2 (...) to Latin-1
DE (D) 1180   Transliteration from Latin-2 (...) to Latin-1
PL (L) 1180   Transliteration from Latin-2 (...) to Latin-1
ES (S) 1180   Transliteration from Latin-2 (...) to Latin-1
T a s k s :
Required OS locales and their current status:
Locale installed     = the locale is installed correctly
Set locale failed    = the locale needs to be corrected on the app server
citmb07_TMB_07       de_DE.ISO-8859-1               Locale installed
                     en_US.ISO-8859-1               Locale installed
                     fr_FR.ISO-8859-1               Locale installed
                     de_DE.ISO-8859-1               Locale installed
                     es_ES.ISO-8859-1               Locale installed
Required profile parameter modifications:
RSCPINST does NOT change the value of profile parameter.
Please check the value of below parameter(s) after activation.
1) Please update zcsa/installed_languages.
    e.g. Copy the new value and paste it into a field in transaction RZ10
New:                  DEFLS
Current (sorted):
citmb07_TMB_07       DEFLS
2) Please proceed with Check result for below parameter(s):
OK     Checked and no inconsistency found.
Regards Peter

Error during Unicode Conversion at DDNTF table

Hello
We are doing a Unicode Conversion for our CRT systems. This system now
is a SAP CRM 7.0 SR1 ABAP.
We have performed preparatory steps (SPUMG, checks, updating R3load,
R3ldctl, R3szchk, dboralib, ...),
but when we start Import process we get an error in SAPSDIC package.
The error looks like:
*************************+
(RTF) ########## WARNING ###########
Without ORDER BY PRIMARY KEY the exported data may be unusable
for some databases
(EXP) INFO: table DDNTF will be exported with sorting
(RSCP) ERROR: 'DDNTF' in UMGCCTL: Guess has illegal value.
(RSCP) WARN: DDNTF: Missing in UMGSTAT,
ERROR in nametab conversion
conversion of nametab table 'DDNTF ':
rscpMCStartTab: rc = 128
(CNV) ERROR: data conversion failed. rc = 2
(DB) INFO: disconnected from DB
/usr/sap/CRT/SYS/exe/run/R3load: job finished with 1 error(s)
/usr/sap/CRT/SYS/exe/run/R3load: END OF LOG: 20091229193651
Any idea??
Thanks in advance
Regards

Yes I executed this Report using Menu Tool Bar.
The first execution gave me some errors regarding some tables existing at database level but not in DDIC. We ignored this errrors because those tables are not important.
But the last try, we decided solve this inconsistencies deleteting those tables at database level, repeting report RADUCNT (in this case no errors appeared) and repeting the export with the same error..
Now, we have seen in Tabscript STATUS of SPUMG there are some errors regarding DDNTF inconsistency found at table control. Reason 4. But this reason means that faillback codepage missing at table control for this table. But as far I know, I can't fill failbak field for this kind of table...
So know I'm reseting SPUMG, and reestarting again..
But I don't understand what is the problem
In a few minutes I will you inform about results
Meanwhile is anybody have any suggestion or idea... please let me know
Thanks!

Effort estimate (ABAP) during Unicode Conversion project

Hi ,
I am working on a CU&UC (Combined Upgrade and Unicode Conversion) project from 46C to ECC6.
We are having 8 different codepages (MDMP SYSTEM) and around 10000 custom objects.
Does anyone have any experince in doing such kind of project ? I am looking at the effort estimate on technical side (ABAP) and functional side.
Any inputs of Technical effort in such a project with related number of codepages and custom objects will be useful (in man days & project duration).
Thanks
Dilip

Hi Dilip,
the main effort from ABAP side seems to be testing of the new system and creating the Unicode vocabulary. You need test teams and test plans for all locations and for the vocabulary you need people for all your languages. ABAP coding itself is probably not your biggest problem. You have to switch your system to unicode and then check all your sources. This could be done by a report or transaction (check the documentation regarding the Migration). From my point of view this is the main effort you'll have, testing and building the vocabulary. How big this effort is depends on your system. I think six month are a good time frame for the whole project (I assume you migrate a landscape of 3 systems). Because I'm working in the Basis administration I could not tell you the exact man days, but I would estimate up to two weeks for the vocabulary per language. You should have the numbers for the system tests from previous upgrades.
The technical migration effort depends on your hardware and time requirements. If your system is big (TBytes) and your downtime is very limited it could be necessary to tune the migration by testing it several times. If your requirements are not that high, then a single test migration could be sufficient. I've done two bigger migrations with 2.5 and 3.5 TB in less than 24 hours but therefore you have to have fast hardware and you have to tune your process well. If you have a single huge table this could destroy all efforts reaching your time target, if for example the index build could not be done in less then your time target. If you have enough hardware resources and time to tune your migration you could reach almost any time (which makes sense - some hours).
Best regards
Ralph Ganszky

Doubt about unicode conversion

Dear Friends,
I have a doubt about the unicode conversion. I have read (one server strategy) that I have to do export (R3load), delete the ECC 6.0 non-unicode, install an unicode database and then import with R3load. My doubt is about the deletion of ECC 6.0 non unicode. Why? can I convert to unicode only with an export (R3load) and subsequent import (R3load) without any deletion?. Obviously I must to change the SAP kernel with a unicode one. Is it correct?
Cheers

you can not convert a SAP System to unicode by just exchanging the executables from non unicode to unicode ones.
a non unicode SAP Oracle database is typically running with a database codepage WE8DEC or US7ASCII (well this one is out of support).
so every string stored in the database is stored using this codepages or SAP-Internal codepages.
When converting to unicode you have to convert also the contents of the database to unicode. As unicode implementation starts at a time where Oracle did not support mixed codepage databases (one tablespace codepage WE8DEC the other one UTF8) inplace conversions are not possible. To keep things simpler, we still do not support mixed codepage databases.
Therefore you have to export the contents of your database and import it to a newly created database with a different codepage if you want to migrate to unicode.
regards
Peter

Unicode Conversion in Downtime Minimized Strategy

Hi,
Whether a Unicode Conversion can be done in a Downtime Minimized Strategy as what we have in Application Upgrade?
Regards,
Sam

No. Unicode conversion can be a easy project or a big project it depends on many factors lke developments, languages installed, product version, etc...
One of the steps of unicode conversion, is the EXPORT and IMPORT. During this time your system is unavailable.
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/unicode/unicode%2bfaq
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_i18/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d393238373239%7d
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5001004f-ce99-2910-8fa9-c5e564a5f318
https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes/sdn_oss_bc_i18/~form/handler%7b5f4150503d3030323030363832353030303030303031393732265f4556454e543d444953504c4159265f4e4e554d3d363535333331%7d
cheers

Print Servers Impact after unicode conversion

Hi
We are performing an CUUC from 4.6C to ECC 6.0
Our customer has around 4-5 windows special print servers which are used for chinese, japanese, korean printing..etc.
After the upgrade & unicode conversion
- Do we still need to use all these 4-5 special print servers for each languages seperatly? or
- We shall consolidate all these print servers into one print server? Or
- We don't need to have any print servers, all the print queues can be pointed to unix print queues and then to the printers directly.
Kindly advise
Thanks & Regards
Senthil

I would think you could consolidate the print servers, but you still need the separate printers/device types in SAP. We use a single print server for EN/DE/ZH but have different SAP printers (usinging different device types) for EN/DE & ZH printers.

SCM Unicode Conversion - Initialize LC or not??

We have recently upgraded our non unicode SCM 5.0 systems to SCM7 EhP3 and we now want to convert these systems to Unicode.
We will be running most of the unicode conversions in situ, ie run all the unicode conversion steps and /SAPAPO/OM_LC_DOWNLOAD_UPLOAD (A&B) , export the database, drop the original non unicode system, reinstall a unicode SCM system and then import the database, followed by /SAPAPO/OM_LC_DOWNLOAD_UPLOAD (C) etc..
On one of the servers however we have 2 SCM systems installed and will use the unicode conversion to move one of the SCM systems to a new server during the database export/import phase, so finally down to my questions!
1) For the in situ Unicode conversions, I take it that we DO NOT have to initialize LC when reinstalling the Unicode SCM system and that we can use param_put DEFAULT_CODE Unicode and alter user SAP<SID> DEFAULTCODE UNICODE before running Step C of /SAPAPO/OM_LC_DOWNLOAD_UPLOAD?
2) For the Unicode conversion including the database export/import (homogenous system copy) to the new server, do we have to initalize livecache as part of the SCM install?
Regards,
Mark

Hi Mark,
Please cehck below thread,
Restore backup of a Non Unicode to a Unicode Live Cache
1319517 - Unicode Collection Note
BR
AKJ

Clarfication of steps in Unicode Conversion

Hello All,
Currently we are upgrading from 4.6C non-unicode to ECC 6.0 with Enhancement Package 4 unicode. I have read the guide for Combined Upgrade and Unicode conversion and understand that as pre-requisite we need to execute the following steps:
Execute report for SDBI_CLUSTER_CHECK for initial cluster records
RADNTLANG - Text language for customer objects
Can you please let me know should I execute this in 4.6C system itself or just before exporting. I have tried these reports in 4.6C system itself but the program do not exists. Hence i assume that this should be done just before export. Can anyone please confirm the same?
Regards,
Anand

You will need to check CU&UC guide, there is mentioned also minimum SP level etc.
I recommend to check also unicode wiki page: http://wiki.sdn.sap.com/wiki/display/unicode/Main

Migration Key for Unicode conversion

Hi,
I want to do a unicode conversion off ECC 6.0. The system was upgraded few days back from R/3 4.7 to ECC 6.0. Now it is required to convert the system to unicode. So to do the activity do we require Migration Key or any other approval from SAP for them to support us?
Thanks,
Suman

If you don't change the platform no migration key is required and no intervention or migration consultant necessary.
Depending on the number of languages/codepages it would probably make sense to get a Basis consultant (maybe remotely will be sufficient) to assist.
Markus

Unicode conversion for ERP

Morning!
In that famous OSS note about unicode conversion, the attached guides are labeled
as NW unicode conversion guides.
-- ERP can use the same guides?
-- how about the unicode conversion for other products such as SM, SCM, CRM, etc.?
Thank you!

Hi,
Answer to both the questions would be Yes. The conversion guides are as per the Netweaver base release for any of the applications (ERP, SCM, SRM, CRM etc).
Eg, If converting a CRM 2005 Non-Unicode to Unicode, the guide SCP700SP<xx> would be relevant, because the Netweaver 700 SP<xx> is the base release for CRM 2005. Similarly for all applications.
Regards,
Srikishan

Error while database export in package SAPDODS_33 (Unicode conversion)

Hello,
I am performing Unicode conversion on an upgraded BI 7.0 system. This is running on AIX/DB2.
When I take database export for conversion, one package fails (SAPDODS_33) with error "The file system is full". In fact, df -k doesn't show that any file system is full.
I am taking the export to the following location: /db2/BWS/sapdata/EXPORT_DIR
There are 3 system-managed temporary tablespaces: PSAPTEMP, PSATEMP16 & SYSTOOLSTMPSPACE which were residing in /db2/BWS/saptemp1/NODE0000. This was getting full during the export. Now these temp.tablespaces have been relocated to a new file system of size 15GB.
But still the package SAPDODS_33 doesn't get exported. Could you please let me know how to solve this issue?
Thanks a lot!
Sundar.
=====================================================================================
SAPDODS_33.log
(DB) INFO: connected to DB
(rscpsumg) Please look also into "SAPDODS_33012.xml".
(rscpMC) Warn: env I18N_NAMETAB_TIMESTAMPS = IGNORE
(rscpMC) Warn: UMGCONTAINER has 1 problems.
(rscpMC) Warn: Global fallback code page = 1160
(rscpMC) Warn: Common character set is not 7-bit-ASCII
(rscpMC) Warn: Collision resolution method is 'fine'
(rscpMC) Warn: R3trans code pages = Normal
(rscpMC) Warn: EXPORT TO ... code pages = Normal
(rscpMC) Warn: Source is 'MDMP'
(rscpMC) Warn: I18N_NAMETAB_NORM_ALLOW = 0
(rscpMC) Warn: I18N_NAMETAB_NORM_LOG   = 0
(rscpMC) Warn: I18N_NAMETAB_ALT_ALLOW = 0
(rscpMC) Warn: I18N_NAMETAB_ALT_LOG    = 0
(rscpMC) Warn: I18N_NAMETAB_OLD_ALLOW = 0
(rscpMC) Warn: I18N_NAMETAB_OLD_LOG    = 0
(GSI) INFO: dbname   = "BWS
(GSI) INFO: vname    = "DB6                             "
(GSI) INFO: hostname = "UNKNOWN
(GSI) INFO: sysname = "AIX"
(GSI) INFO: nodename = "itmlartdev01x"
(GSI) INFO: release = "3"
(GSI) INFO: version = "5"
(GSI) INFO: machine = "002417CA4C00"
(GSI) INFO: instno   = "0020169337"
(EXP) ERROR: DbSlExeRead failed
rc = 99, table "/BIC/B0000786000"
(SQL error -968)
error message returned by DbSl:
SQL0968C The file system is full. SQLSTATE=57011
(DB) INFO: disconnected from DB
/usr/sap/BWS/SYS/exe/run/R3load: job finished with 1 error(s)
/usr/sap/BWS/SYS/exe/run/R3load: END OF LOG: 20071211053119
p/sapinst/sapinst_instdir/NW04S/LM/COPY/DB6/EXP/CENTRAL/AS-ABAP/EXP #

Hi Sundar,
if the problem is due to a high temp space usage. The root cause is typically the
sort during export. If the table is large, the sort spills to temp.
You can avoid the sort by doing an unsorted export or tweak the DB2 optimizer to use the primary key to do the sort.
Before DB2 9, you can reduce the OVERHEAD tablespace parameter to zero. Return this value to its previous value after the successful export. This is a indirect hint to the optimizer that random IOs are cheap. This might not help.
With DB2 9, this should not happen, because the DB2_OPT_MAX_TEMP_SIZE=10240 registry variable is set under DB2_WORKLOAD=SAP which limits the temp space usage to 10GB if possible. You can reduce this parameter further if necessary. Another problem could be that the optimizer has chosen the wrong temp space. The optimizer choses the temp space with the largest amount of pages (not size).
Regards, Jens

Unicode conversion, blended codepages etc

Similar Messages

Maybe you are looking for