Unicode Conversion approach

HI All
During Unicode approach isit possible to do the conversion of custom and standard program to unicode and make the system live and later on do the data conversion with business downtime.
The reason i am asking so as to reduce the business down time. We are going for CU&UC and donot want a long business downtime.
Let me know if there are any approach where we can do the data conversion in the later phase.
Thanks
Rajat Sarkar

Hi,
please have a look at:
http://service.sap.com/~form/sapnet?_SHORTKEY=01100035870000380759&_OBJECT=011000358700000620342009E
> Page 21
Excerpt begin:
1) Start release >= SAP NetWeaver AS 6.20
> UCCHECK can be run before or during Unicode conversion
2) Start release <= 4.6C (CU&UC or TU&UC*)
> Execute the whole UCCHECK procedure in the SBX Unicode system
> Upgrade the DEV system to SAP ERP 6.0 (Non-Unicode or Unicode) and execute UCCHECK (Additional Maintenance System necessary)
Excerpt End.
Therefore if you have a 4.6c system (or lower) as source system, then the Unicode enabling procedure (UCCHECK) cannot be separated from the actual Unicode conversion (Export / Import). In case of NW 6.20 or higher, you can do most of the enabling before the conversion (you will still need a rework after the conversion).
Best regards,
Nils Buerckel

Similar Messages

SAP R/3 4.6 C to ECC 6.0 Upgrade using CU &UC method- Unicode conversion

Basis Gurus
   I am working on upgrade from R/3 4.6C to ECC 6.0.
ECC 6.0 upgrade completed( still in non Unicode). Now I am in the process of Unicode conversion.
I have used following methods for the upgrade.
1. Combined Upgrade & Unicode conversion(CU & UC)
2. Resource minimized( as I am doing it in Sandbox).
As I understand I need to perform the DB export and Import now for the unicode conversion.
According to the Upgrade document, First I need to run Export using R3load in ECC6.0(Non unicode)
and then install Unicode system and import the same data file.
My understanding was, when I choose, Resource minimized, I need to run Export and import
in the same system.
Can you please help me , whether I need another Unicode system for import ??
Graham

Hi,
Dont get confused with upg strategy and unicode conversion.
In general Upgrade strategy (either downtime-minimized/resource minimized)
In unicode conversion you have export/import(exp/imp) of data concept
In CU&UC approach you have to do in a streach to complete migrate from old release to new realease ECC 6.00.
Using database independent (sapinst only) or Using database dependent (migration monitor or Distribution monitor)
It can be done in 2 ways.
If you dont have addtional server for unicode conversion
       1)you can either do exp on same hardware and take bakup and do import using the exp dump.
       2)Do exp on one server and prepare your target empty database on another server and complete imp of data.
Hope this is clear.
Regards,
Vamshi.

4.7EEx1.10 to ECC6.0 upgrade and Unicode conversion

Hi Experts,
We are going to initiate the upgrade from next month onwards. Subsequently i have started preparing the plan and strategy for the same.
As our current setup is 4.7EEx110/Win 2003 R2-64 bit/Oracle 10.2.0.4.0 (Non unicode). And we have recently migrated on to this setup from WIn2k 32 bit. Also the current hardware is Unicode compatible.
With respect to strategy for achieving this Upgrade and Unicode conversion, i am planning as follows.
Step 1) Perform Unicode conversion on the current landscape (Both Export/import on the same servers)
Step 2) Setup Temporary landscape as part of Dual maintenance strategy and migrate data from the current systems to temporary systems using backup/restore method.
Step 3) Perform the SAP version upgrade on the current landscape and setup transport routes from temporary to current landscape in order to keep it in sync
Step 4) after successful upgrade, decommission the temporary landscape
Please provide your suggestions and valuable advices if there is anything wrong with my strategy and execution plan.
Regards,
Dheeraj

Hi,
Thanks. As i have already referred these notes as i am seeking advise with respect to my upgrade approach.
However i have planned to perform in the following manner.
1) Refresh Sandbox with Prod data and perform Upgrade to ECC6.0 EHP5 & subsequently Unicode conversion on the same server (Since both export & Import has to perform on the same hardware as we have recently migrated on this hardware which is Unicode compatible)
2) Setup temporary landscape for DEv & QAs and establish transport connection to Production system in order to move urgent changes
3) Keep a track of the changes which have transported during upgrade phase so that the same can be implemented in the upgraded systems i.e. Dev & QAS
4) After Sandbox Migration and signoff, we will perform Dev & QAS upgrade & unicode conversion on the same hardware (Note: Since these are running on VMware can we export the data from the upgraded system and import on to a new VM?)
5) Plan for production cutover and Upgrade the Prod system to ECC6.0 Ehp5 and then Unicode conversion. As i am planning to perform upgrade over the weekend and then Unicode conversion activity in the next weekend (Is it a right way?)
My Production setup: DB on one Physical host and CI on separate Virtual host
6) After the stabilization phase, we are planning for OS & DB upgrade as follows:
a) Windows upgrade from 2003 R2 to Windows 2008 R2
b) Oracle Upgrade from 10.2 to 11.2
If anyone thinks that there is anything wrong with my above approach and need changes then please revert.
I have one more doubt as I am going to upgrade 4.7EEx110 (WAS 620, Basis SP64) to ECC6.0 EHp5.As I presume that I can straight away upgrade from the current version to ECC6.0 Ehp5 without installing EHP. Kindly confirm
Thanks

Minimize downtime during UNICODE conversion

Hello forum !
I am looking at the UNICODE conversion of a large (?) SAP Oracle database for ECC. The Database it self is at about 10 TB. UNICODE converting this in one single run will take too long to fit inside the company defined tolerable downtime window.
When looking at the data I find that the largest 50 tables makes up about 75% of the total database size. Most of the 50 largest tables have data for several years back, and I am able to partition the tables with one partition pr year.
The good thing about this is that I am able to make the partitions with old data (more than one year old data) READ-ONLY.
My assumption is that I will be able to UNICODE convert 60-70% and create the indexes for these partitions without taking down the database to be converted.
Now,- doing the downtime-phase I will be able to exclude the old partitions of the largest tables in the export since I have already created a new UNICODE database with these objects and thereby drastically reducing the required downtime.
Is there anyone who has any experience with an approach like the one I have schetched out here ?
Kjell Erik Furnes

Can you please be a bit more specific on your installation? How long is your possible downtime (export time should be about 2/3 of that)? How long is your actual export estimation? Do you have suitable hardware (CPU/disk)?
What you absolutely need to have:
[1043380 - Efficient Table Splitting for Oracle Databases|https://service.sap.com/sap/support/notes/1043380] -> export tables with ROWID splitting
[855772 - Distribution Monitor|https://service.sap.com/sap/support/notes/855772] -> enables distributed and parallel export/import
So on the hardware side you will need, a storage subsystem as fast as possible with two copies of the disks (one for exporting and one for importing). A bunch of application servers with fast CPUs helps a lot, everything connected with at least gigabit ethernet.
If you knew all this already, sorry for the spam. But i achived throughputs at about 400gb/hour on a medium sized hardware, i think throughputs of 1tb/hour should be possible (not talking about cluster tables
Regards, Michael

MDMP unicode conversion - Vocabulary maintenace

Hello,
W have upgraded 4.5B MDMP system to ECC4 EHP4 and now we are in process of unicode conversion.
please advice on as specified below.
In SPUMG Scan process, we have completed the following scans:
a) Tables without language Info
b) Tables with Ambiguous language Info
c) Indx Analysis
For maintaining vocabulary we have implemented notes 756534 & 756535, 871541. and Tables with language are also scanned. While handling vocabulary the system has displays 539158 with duplicates and 189314 when duplicates are discarded, which doesnot assigened any languages. We have 9 acive languages.
As per Unicode conversion document i left out with only 2 more option a) HInt management b) Manual assignment
How to handle this? is this a normal situation or any correction can be done?
Thanks and Regards
Vinay

Hi Vinay,
This Thread belongs to the Unicode forum:
Internationalization and Unicode
In my opinion one of the best and most efficient possibility to reduce the number of words
is to make use of hints. Please follow the Unicode Conversion Guide and SAP note 1034188.
Application colleagues should be contacted in order to find proper hints.
Please also note that report umg_vocabulary_statistic or um4_vocabulary_statistic is the best tool to evaluate tables for hint processing.
And the rest of the vocab, which can not be assigned by the hints method or by the SAP notes you mentioned, need to be assigned by native speakers (manual effort !).
As you can see, SPUMG is NOT just a tool to be executed by Basis staff.
It needs in deed collaboration between Basis, Application and native speakers.
And it should be clear that the duration of the scans can be quite high - therefore a trial & error approach will take time (especially for large systems).
Best regards,
Nils Buerckel
SAP AG

Single Code Page Unicode conversion when source and target are the same

Hi everyone. We have recently upgraded our non-unicode 4.7 to ECC6 non-unicode. Now we have begun researching the next step to convert to Unicode. I know we could have done the Combined Upgrade and Unicode Conversion but I wanted to do thorough testing after the upgrade to eliminate too many variables if problems arose.
So, my question is...has anyone done the Unicode conversion when source and target servers are the same? Most documentation I've seen recommends a system copy to another box first. I did find one forum thread that gave a high level approach to doing the conversion with just one server and listed this:
Step 1:- Run Tcode SPUMG to scan
Step 2:- Export Database
Step 3:- Drop Database
Step 4:- Create New Database
Step 5:- Import database
Step 6:- Chnage unicode Kernel
What are your thoughts? Is it supported? Am I wasting my time and should I just bite the bullet and buy yet another system? Thanks in advance.
-Anthony

Theoretically that's possible, yes. However...
> Step 5:- Import database
> Step 6:- Chnage unicode Kernel
the import must be done using the Unicode kernel.
So basically you can
- export the old systm
- uninstall system + database
- start as if you were installing "from scratch" on a new box
Markus

Unicode conversion in NonUnicode system

We are undertaking a project to make all Z* programs Unicode compatible in Non-unicdoe system.
Any suggestions to approach this tasks is welcome..
Thanks.

Below link will give idea about Unicode conversion
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c0ff71ca-1d11-2a10-6a93-88662a6e7bc9

Unicode conversion - space allocation

Hi All -
We are starting to look at converting our system to Unicode this summer, and I'm worried that we have enough space allocated on UNIX box to allow for successful conversion!
I have read the Unicode conversion guide for allocating additional space to tablespaces on the database, but does anyone have any words of caution / wisdsom for non-tablespace related space needs during a Unicode conversion? For example, I think I have all our /oracle/[sid]/sapdata directories accounted for - I am just trying to determine if I'm missing anything else.
Input is appreciated. Thanks!
Abby

Hi Abby,
additional Hardware requirements due to Unicode are described in SAP note 1139642.
There are no general rules for the additional hardware components needed for a Unicode conversion.
This highly depends on your planned scenario (One Server inplace / new Unicode server) and your downtime requirements. But even knowing the details no one will be able to give exact figures.
If you are lucky, you might find someone who did a similar scenario on comparable hardware.
However we highly recommend to plan for a Sandbox conversion (with a copy of your PRD system), which will be the best approach to find out reliable downtime figures and possible hardware bottlenecks.
Please also have a look at SAP note 857081.
Best regards,
Nils Buerckel
SAP AG

Unicode conversion and patching simultaneously

Hi All -
We are planning to convert our core ECC 6.0 system to Unicode this year as well as patch it to the latest support pack stack. In order to minimize regression testing time, we are going to do them both at the same time so the functional teams only have to test once.
The question is which order to perform the tasks in: convert to Unicode first, THEN patch, or patch, THEN convert? I'm not sure the order matters, but I can't find any definite documentation either way. Has anyone had any experience with this that they would be willing to share?
Thanks for your help!
Abby

Hi Abby,
this depends on what you mean by "patches" ?
Do you want to combine the Unicode conversion with applying support packages only ?
Or do you want to implement EhPs as well ?
If you go for EhPs, I would recommend to do this before the Unicode conversion. This is also the "normal" approach when combining an upgrade with a Unicode conversion.
In case of support packages only, both ways are possible (Unicode first and then SPs or vice versa) ...
By the way I assume you do not have an MDMP system - this would add some additional constraints ...
Best regards,
Nils Buerckel
SAP AG

What's the best solution Unicode Conversion and Upgrade on AS 400

Hi Guys,
We have a R/3 4.6C system on AS400 server. Within this year, we' like to change hardware and DB vendor (Oracle), in the meantime we also need to perform the UC and upgrade to ECC6.0.
What 's the best scenario? we have below suggestions.
1
Step1 - Heterogeneous migration and perform UC to new server and DB in one migration (export / import)
Step2 - Upgrade ECC6.0 Unicode
(not sure about this solution, is Unicode conversion to 4.6C without upgrade possible?????)
2
Step1 - Heterogeneous migration to new server and DB
Step2 - UC&UP
3
Step 1 - Heterogeneous migration to new server and DB
Step 2 - Upgrade to ECC non-unicode
Step3 - Unicode conversion to ECC unicode
????? which is better? 2 big question
- is Unicode conversion to 4.6C without upgrade possible?????)
- what's the difference between UC&UP and upgrade first and perform UC later, which is better?
Thanks very much
Lin
Edited by: ye zhulin on Mar 8, 2010 9:53 AM

Hi Lin,
I assume you have an EBCDIC database at the moment.
Point 1 is not possible, since 4.6C is not supported with Unicode.
The difference between CU&UC and a separate Upgrade and a later Unicode conversion is that CU&UC is done in one downtime. However you need to evaluate whether this is possible with your downtime requirements.
My recommendation would be to do the Migration and after that the CU&UC approach (if this is possible in a feasible downtime window - this is highly dependent on your system size / downtime requs / hardware capabilities).
Best regards,
Nils Buerckel
SAP AG
Edited by: Nils Buerckel on Mar 8, 2010 10:34 AM

SAP 4.7 Ext 110 Unicode Conversion

We are Currently on
SAP 4.7 EXT 110 on AIX 5.2 / Oracle 9.x
We are planning to Convert the Existing 4.7 System to Unicode. I'm aware that 4.7 is already in extended maintanence and it is recommended to Upgrade to ECC 6.0 Unicode. However the Business decision is to Convert the existing SAP 4.7 Ext 110 to Unicode.
a) What is the Approach for this?
b) Do I need an Complete Target hardware other than the Mock hardware. What i mean here is
                    whether I can use the existing hardware for DEV,QAS,PRD
                                                                      or
                     Purchase a New Hardware for DEV,QAS, PRD.
c) Please let me know if there are challenges in Converting SAP 4.7 Ext 110 system to Unicode. If yes please help me in understanding.

Dear Nils
If you can help me in understanding the Advantages & Disadvantages of Two sever method and Having a Parallel landscape for Unicode , would be helpful
Current Landscape : DEV,QAS,PRD
a) Two server method : SBX for Copy of PRD , SBU for Unicode conversion . No Parallel landscape
The Movement you convert your DEV to Unicode , DEV is Unicode and QA is non-Unicode and PRD as well.
Is there a risk here?
b) With a Parallel landscape NEWDEV,NEWQAS,NEWPRD
Can we use the NEWPRD for mock ?
a) Mock -NEWPRD can be used as SBX for Mock and NEWQA can used as SBU for Unicode conversion
b) DEV-> Copy DEV NEWPRD (SBX) and use NEWDEV as SBU for Unicode conversion
c) QAS-> Copy PRD to NewPRD(SBX) and Use NewQAS as SBU for Unicode conversion
d) Rehearsal Export from PRD and Import in NEW PRD with Unicode kernel
What is advantage and disadvantage/Risk in the above two approaches

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

Combined Upgrade and Unicode conversion of Sap 4.6C to ECC6.0

Hello all,
my project team intends to carry out a combined upgrade and unicode conversion of an SAP ERP 4.6C system with MDMP to ECC6.0 (no enhancement package). The system is running on Oracle 10.2.
In preparation for this upgrade, I have gone through the SAP notes 928729, 54801.
We need to get a rough estimate of the entire downtime so as to alert our end users. From the CU&UC documentation in 928729, I read up note 857081. However the program in this note cannot be used to estimate the downtime as my system is < SAP netweaver 6.20.
Is there any other SAP note or tool or program that I can use to estimate the downtime for the entire CU&UC? Thanks a lot!

Hi,
Combined upgrade depend upon number of factors like database size, resources on the server and optimization. In order to get idea of how much downtime, it will take, I would suggest you to do combined upgrade and unicode conversion on sandbox system which should be the replica of your production system. And try to optimize it. From there you can get approx. downtime required.
Also, please read combined upgrade and unicode conversion guides on http://service.sap.com/unicode@sap
Thanks
Sunny

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

Unicode conversion in situ

Hi SCN,
I'm looking at the possibility of running a Combined Upgrade & Unicode Conversion (CUUC) in-situ; i.e. without a migration to new hardware.
However in all my years of SAP Basis projects any Unicode conversion I've seen has involved a migration to new hardware (which makes good sense as the process is the same as an OSDB migration with R3load/MigMon).
What I want to know is - has anyone ever run one in-place. I.e. keeping the same server and running the CUUC entirely inplace?
This seems logically problematic as you need a target system to import to.
I can imagine a process along these lines though...:
1. Take SAP layer offline
2. Run full backup of system
3. Export system
4. Drop database* (to make clean ready for new import)
5. Run SPUMG/SUMG/SAPINST to setup Unicode database ready to receive import...
6. ....and continue to run import into that database
7. Complete Unicode conversion process
However the big issue here for me is
(a) *dropping the live production system is far from attractive.... I'm presuming everyone would do as I've always seen and combine this with a migration to new improved hardware, so that a backout to the old system is simple
(b) I'm not sure at what point with the SAP tools (SPUMG/SUMG/SAPINST) this process would become convoluted with it all being in-situ on the same box. I.e. I'm not sure if it's something the SAP tools are really designed to cater for.
Any input/discussion on these points would be very welcome.
Regards, doonan_79

FYI Community. Feeling after reading and research is to use a temorary server to import unicode converted system data into; then swing disks back to the original host. Making all required hostname updates during the process.
Allowing for parallel export/import, but going back to the original configured host to complete the process.

Unicode Conversion approach

Similar Messages

Maybe you are looking for