UCCHECK downporting

Hello All,
we are planning for a CU&UC (Combined upgrade and unicode coonversion) from 4.6C system to ECC600, but as UCCHECK is not available in 4.6C system we are unable to do the Unicode Conversion Imapact analysis, is there any another way for the same? can we downport UCCHECK to 4.6C system?
SAP Recommands :
•     Create a sandbox system on release 6.10 or higher. Create a transport with your own programs and modified SAP programs in your R/3 4.6C system and import them into the sandbox system. Perform the preparation steps.
•     Copy your R/3 4.6C system and upgrade to release 6.10 or higher (non-Unicode). Perform the preparation steps.
Thanks in advance.
Best Regards,
Sachin.

Hi Sachin,
as you already mentioned UCCHECK is not available in 46C.
But you not neccesarily need an additional system for this check.
If you first upgrade DEV, you can perform the required checks direct after upgrade, before unicode conversion. Even if this need a little more time.
Regards
Guido

Similar Messages

  • View maintenence problem in UCCHECK?

    Hi everyone,
    Does anyone know anything about the unicode error 'VIEW'. I got this when I executed the tcode UCCHECK.
    The message I got is:
    'Generated Code for View Maintenance Dialog is not Unicode-Compatible You can regenerate with the program RSVIMT_UC_VIEW_MAINT_GEN'.
    I tried to regenrate with the current program, but no use.
    I read in one of the threads, that if we set the unicode checks active flag in the error program it will be solved.
    Tried it but no result again.
    I even tried to activate the view related to this program in SE11, as you can expect didn't work again.
    So has anyone ever come across this problem? if so please help me in solving this.
    Thank you all in anticipation.
    Goldie.

    hi ,
    You need to use the transaction UCCHECK.
    The report documentation is here
    ABAP Unicode Scan Tool UCCHECK
    You can use transaction UCCHECK to examine a Unicode program set for syntax errors without having to set the program attribute "Unicode checks active" for every individual program. From the list of Unicode syntax errors, you can go directly to the affected programs and remove the errors. It is also possible to automatically create transport requests and set the Unicode program attribute for a program set.
    Some application-specific checks, which draw your attention to program points that are not Unicode-compatible, are also integrated.
    Selection of Objects:
    The program objects can be selected according to object name, object type, author (TADIR), package, and original system. For the Unicode syntax check, only object types for which an independent syntax check can be carried out are appropriate. The following object types are possibilities:
    PROG Report
    CLAS Class
    FUGR Function groups
    FUGX Function group (with customer include, customer area)
    FUGS Function group (with customer include, SAP area)
    LDBA Logical Database
    CNTX Context
    TYPE Type pool
    INTF Interface
    Only Examine Programs with Non-Activated Unicode Flag
    By default, the system only displays program objects that have not yet set the Unicode attribute. If you want to use UCCHECK to process program objects that have already set the attribute, you can deactivate this option.
    Only Objects with TADIR Entry
    By default, the system only displays program objects with a TADIR entry. If you want to examine programs that don't have a TADIR entry, for example locally generated programs without a package, you can deactivate this option.
    Exclude Packages $*
    By default, the system does not display program objects that are in a local, non-transportable package. If you want to examine programs that are in such a package, you can deactivate this option.
    Display Modified SAP Programs Also
    By default, SAP programs are not checked in customer systems. If you also want to check SAP programs that were modified in a customer system (see transaction SE95), you can activate this option.
    Maximum Number of Programs:
    To avoid timeouts or unexpectedly long waiting times, the maximum number of program objects is preset to 50. If you want to examine more objects, you must increase the maximum number or run a SAMT scan (general program set processing). The latter also has the advantage that the data is stored persistently. Proceed as follows:
    Call transaction SAMT
    Create task with program RSUNISCAN_FINAL, subroutine SAMT_SEARCH
    For further information refer to documentation for transaction SAMT.
    Displaying Points that Cannot Be Analyzed Statically
    If you choose this option, you get an overview of the program points, where a static check for Unicode syntax errors is not possible. This can be the case if, for example, parameters or field symbols are not typed or you are accessing a field or structure with variable length/offset. At these points the system only tests at runtime whether the code is sufficient for the stricter Unicode tests. If possible, you should assign types to the variables used, otherwise you must check runtime behavior after the Unicode attribute has been set.
    To be able to differentiate between your own and foreign code (for example when using standard includes or generated includes), there is a selection option for the includes to be displayed. By default, the system excludes the standard includes of the view maintenance LSVIM* from the display, because they cause a large number of messages that are not relevant for the Unicode conversion. It is recommended that you also exclude the generated function group-specific includes of the view maintenance (usually L<function group name>F00 and L<function group name>I00) from the display.
    Similarly to the process in the extended syntax check, you can hide the warning using the pseudo comment ("#EC *).
    Applikation-Specific Checks
    These checks indicate program points that represent a public interface but are not Unicode-compatible. Under Unicode, the corresponding interfaces change according to the referenced documentation and must be adapted appropriately.
    View Maintenance
    Parts of the view maintenance generated in older releases are not Unicode-compatible. The relevant parts can be regenerated with a service report.
    UPLOAD/DOWNLOAD
    The function modules UPLOAD, DOWNLOAD or WS_UPLOAD and WS_DOWNLOAD are obsolete and cannot run under Unicode. Refer to the documentation for these modules to find out which routines serve as replacements.
    http://www.pac.co.il/infoweek/Resources%5CKeter_ECC6_Upgrade_Presentation_170107.ppt
    The above link gives u a power point file on ecc 6.0 updation and what are required .
    Check the below links for understanding of unicode.
    UCCHECK downporting
    UCCHECK
    http://www.sap.com/korea/Company/Events/techday05/img/data_01.pdf
    http://www.sap-press.de/download/dateien/1240/sappress_unicode_in_sap_systems.pdf
    Re: ECC 6.0 Upgrade & changes required in programs
    regards,
    venkat.

  • File download difference in 4.6c and ECC 6.0

    Hi all,
    I have a problem in a program that downloads file. The program in 4.6c and program in 6.o are exactly the same. I am using gui_download to download the file.
    The parameters passed are exactly the same. What is happening is when the file is downloaded in 4.6c , it comes up as
    field1SPACESfield2SPACESfield3.
    Now when I download the same file using same program in 6.0, it comes up as
    field1SPACES[EXtra6space]field2SPACES[EXtra6space]field3.
    That is it adds 6 spaces extra between fields.
    Is it normal? how can i override those 6 spaces?
    thanks,
    RS

    hi ,
    UPLOAD/DOWNLOAD
    The function modules UPLOAD, DOWNLOAD or WS_UPLOAD and WS_DOWNLOAD are obsolete and cannot run under Unicode. Refer to the documentation for these modules to find out which routines serve as replacements.
    http://www.pac.co.il/infoweek/Resources%5CKeter_ECC6_Upgrade_Presentation_170107.ppt
    The above link gives u a power point file on ecc 6.0 updation and what are required .
    Check the below links for understanding of unicode.
    UCCHECK downporting
    UCCHECK
    http://www.sap.com/korea/Company/Events/techday05/img/data_01.pdf
    http://www.sap-press.de/download/dateien/1240/sappress_unicode_in_sap_systems.pdf
    Re: ECC 6.0 Upgrade & changes required in programs
    regards,
    venkat.

  • Making ABAP sources Unicode compliant ... after Unicode conversion

    Hi,
    I was asked by a customer if there is any problem with the following scenario :
    A system must be converted to unicode. Unfortunately, not all the ABAP source codes will be unicode enabled on-time for the conversion.
    The development team wanted to know if they can assign priorities to ABAPs and focus their manpower on these ABAPs only.
    The rest of the ABAPs will be made unicode compliant AFTER the conversion of the system.
    I am well aware that if ABAPs don't have the Unicode flag checked, the system won't allow their execution but will it still be possible to edit the source code of those non unicode ABAPs and enable them afterwards ? From a technical point of view, I can't find any reason why it shouldn't be possible but who knows ...
    Thanks for your answers,

    Hi,
    Yes during upgade the unicode check comes into picture..
    The first unicode version is 4.7,so from 4.7 to higher versions unicode is thre...below 4.7 say 4.c is non unicode .
    one example is u can dclare a variable of type X in non-unicode system(4.6c) but not possible in unicode system(ECC6.0).
    Check the below links for understanding of unicode.
    [UCCHECK downporting;
    [UCCHECK;
    [http://www.sap.com/korea/Company/Events/techday05/img/data_01.pdf]
    [http://www.sap-press.de/download/dateien/1240/sappress_unicode_in_sap_systems.pdf]
    [Re: ECC 6.0 Upgrade & changes required in programs;

  • Warning codes generated in UCCHECK   - Technical Upgrade - 4.0b to ECC 6.0

    Hi SDN'ers ,
    I am currently working on Technical Upgrade project from 4.0 b system to ECC 6.0 system . I am facing a
    problem relating to the analysis of the warnings displayed whehn we run the UCCHECK for the client inventory by
    checking the "Display lines that cannot be analyzed statically" option under the Selection-screen block
    "Statements that cannot be analyzed statically" .Based on the warning codes generated during UCCHECK, they can
    be classified into 12 different categories given below in the list ( Viz. ABB,MESSAGEG!C,MESSAGEG!D......MESSAGEG!P).The same are given below in the end
    I want to know
    - Which are the warning codes which need resolution so that the program does not encounter any runtime
    errors or during Integration testing ?
    - Do all the offset related errors (For example ;variable A = B+offset(length)
    or  variable A+offset(length) = B ) need resolution so that the program gives no runtime error.
    - Also, do all statements where length is calculated using STRLEN also need changes ? I have seen offset length related warnings come under MESSAGEG!M warning code.
    The objective of this is to make sure that the upgraded system ECC 6.0 in Australia ,when rolled out to
    non-English speaking geographies in APAc such as Malaysia,Japan or China would only need translations and no ABAP Coding effort even when using languages such as Japanese which have double byte characters.
    S.No.     Error Code     Message
    1     ABB     Syntax Check Aborted
         ABB Total     
    2     MESSAGEG!C      check at runtime. at runtime.
               statement because of untyped or generic operands. It can only carry out this
              The system could not perform a static convertibility check on the current
         MESSAGEG!C Total     
    3     MESSAGEG!D      out this check at runtime. It can only carry out this check at runtime.
               to a table line because of untyped or generic operands. It can only carry out
              The system could not perform a static check on convertibility from a work area
         MESSAGEG!D Total     
    4     MESSAGEG!E      check at runtime. at runtime.
               defined by a "DATA" statement. .
               statement because of untyped or generic operands. It can only carry out this
              Field "ELEMENTN" is unknown. It is neither in one of the specified tables nor
              The system could not perform a static comparability check on the current
         MESSAGEG!E Total     
    5     MESSAGEG!F      operand "<FELD1>" for the current statement. .
         MESSAGEG!F Total     
    6     MESSAGEG!G      current statement on incompletely typed operand "<DATA>". .
         MESSAGEG!G Total     
    7     MESSAGEG!H      for the incompletely typed operand "<S>". . - - - - - - - - -
              The system cannot perform a static check on a character-type field data type
         MESSAGEG!H Total     
    8     MESSAGEG!I      incompletely-typed operand "<A>" in the current statement. .
              The system cannot perform a static check on a character-type data type for the
         MESSAGEG!I Total     
    9     MESSAGEG!J      "<%_1_SYSINI>" in the current statement to check whether the operand can be
              The system cannot perform a static check on incompletely-typed operand "VALUE"
         MESSAGEG!J Total     
    Early response wil be highly appreciated.

    Hi Karthik
    >
    > 1) SPDD adjustments are done in which phase? PREPARE or UPGRADE?
    >
    SPDD is done in Upgrade ->Phase ACT_700
    > 2) Are here special cases where the adjustments need to be done before running the UPGRADE phase?
    >
    At ACT_700 phase stop the upgrade and take a backup of the DB and the PUT<DIR> before starting the SPDD activity.
    Make sure there are no pending tp request.  Either release them or delete them.
    All phase need to be completed successfully in PREPARE, before starting UPGRADE
    Cheers
    Shaji
    Edited by: Shaji Jacob on May 5, 2008 9:23 PM

  • Warning codes generated in UCCHECK

    Hi SDN'ers ,
    I am currently working on Technical Upgrade project from 4.0 b system to ECC 6.0 system . I am facing a
    problem relating to the analysis of the warnings displayed whehn we run the UCCHECK for the client inventory by
    checking the "Display lines that cannot be analyzed statically" option under the Selection-screen block
    "Statements that cannot be analyzed statically" .Based on the warning codes generated during UCCHECK, they can
    be classified into 12 different categories given below in the list ( Viz. ABB,MESSAGEG!C,MESSAGEG!D......MESSAGEG!P).The same are given below in the end
    I want to know
    - Which are the warning codes which need resolution so that the program does not encounter any runtime
    errors or during Integration testing ?
    - Do all the offset related errors (For example ;variable A = B+offset(length)
    or  variable A+offset(length) = B ) need resolution so that the program gives no runtime error.
    - Also, do all statements where length is calculated using STRLEN also need changes ? I have seen offset length related warnings come under MESSAGEG!M warning code.
    The objective of this is to make sure that the upgraded system ECC 6.0 in Australia ,when rolled out to
    non-English speaking geographies in APAc such as Malaysia,Japan or China would only need translations and no ABAP Coding effort even when using languages such as Japanese which have double byte characters.
    S.No.     Error Code     Message
    1     ABB     Syntax Check Aborted
         ABB Total     
    2     MESSAGEG!C      check at runtime. at runtime.
               statement because of untyped or generic operands. It can only carry out this
              The system could not perform a static convertibility check on the current
         MESSAGEG!C Total     
    3     MESSAGEG!D      out this check at runtime. It can only carry out this check at runtime.
               to a table line because of untyped or generic operands. It can only carry out
              The system could not perform a static check on convertibility from a work area
         MESSAGEG!D Total     
    4     MESSAGEG!E      check at runtime. at runtime.
               defined by a "DATA" statement. .
               statement because of untyped or generic operands. It can only carry out this
              Field "ELEMENTN" is unknown. It is neither in one of the specified tables nor
              The system could not perform a static comparability check on the current
         MESSAGEG!E Total     
    5     MESSAGEG!F      operand "<FELD1>" for the current statement. .
         MESSAGEG!F Total     
    6     MESSAGEG!G      current statement on incompletely typed operand "<DATA>". .
         MESSAGEG!G Total     
    7     MESSAGEG!H      for the incompletely typed operand "<S>". . - - - - - - - - -
              The system cannot perform a static check on a character-type field data type
         MESSAGEG!H Total     
    8     MESSAGEG!I      incompletely-typed operand "<A>" in the current statement. .
              The system cannot perform a static check on a character-type data type for the
         MESSAGEG!I Total     
    9     MESSAGEG!J      "<%_1_SYSINI>" in the current statement to check whether the operand can be
              The system cannot perform a static check on incompletely-typed operand "VALUE"
         MESSAGEG!J Total     
    Early response wil be highly appreciated.
    10     MESSAGEG!K      "<F_YEAR>" in the current statement to check whether the operand can be
              The system cannot perform a static check for incompletely-typed operand "WINY2"
         MESSAGEG!K Total     
    11     MESSAGEG!M      .
               at runtime. .
               check will take place at runtime. .
               entries for operand "<F_SOURCE>(2)". This check will take place at runtime. .
               entries for operand "<F_SOURCE>+2(2)". This check will take place at runtime.
              The system cannot perform a static check on the validity of the offset/length
         MESSAGEG!M Total     
    12     MESSAGEG!P      out this check at runtime. at runtime.
               statement because of untyped or generic operands. The system can only carry
              The system could not perform a static compatibility check on the current
         MESSAGEG!P Total     
         Grand Total

    Hi Monica,
                 as bhaskar said no need to worry about warnings.
    warnings will not lead to dump. only runtime errors will lead to dump.
    if the system is unicode, remediate the objects without errors.
    we can observe mainly,
    open dataset, structure incompatibilty, offset, in byte or char mode etc
    thanks
    vinod

  • Error while running UCCHECK

    Dear all,
    while executing UCCHECK i am getting the following error as shown below.
    Check a Program Set for Syntax Errors in Unicode Environment
    Could not determine program name:
    FUGR                                        GRWT                          SAP         SAP
    Could not determine program name:
    PROG                                        MLDB                          SAP         SAP
    001739 Programs Selected
    However, the maximum number was reached in 000000 programs
    Increase the maximum number of errors for programs, or carry out a scan using SAMT
    I am performing a conversion from ECC 5.0 non-unicode to ECC 5 unicode.
    OS is windows server 2003.
    Kernel is 640 version.
    please help me how to proceed in this regard.
    Your suggestions are highly appreciated.
    Regards,
    chandru

    Usually this issue is caused by entries in the TADIR table which have an
    empty OBJNAME field. This occurs for GRWT and MLDB (it may also occur
    for some $TMP objects). These entries can be removed from table TADIR
    to resolve this issue. Remove the entries in the base client 000.
    Make sure you're not running UCCHECK for SAP standard programs, because this is not necessary as you can see in the Conversion Guide.
    Marco

  • What needs to be corrected in UCCHECK ?

    Hello,
    We need to pass unicode soon so we are executing transaction UCCHECK in our system.
    We don't know really what to put in the selection screen so we put * in all parameters and set checkboxes in order to take the maximum objetcs possible.
    We saw the documentation but it is not clear for us.
    We obtain a very long list of programs in error or in warning, and some other correct.
    Could you tell me if :
    - We need to execute uccheck with the selection I describe you ?
    - Do we need to correct only the errors ? or also the warnings ?
    Thank you for your answers.
    Vanessa Roulier

    Hi,
    The are many documents which are available for how to make the programs Unicode compatible.
    Step 1
    In non-Unicode system
    Adapt all ABAP programs to Unicode syntax and runtime restrictions
    Set attribute "Unicode enabled" for all programs
    Step 2
    Set up a Unicode system
    Unicode kernel + Unicode database
    Only ABAP programs with the Unicode attribute are executable
    Do runtime tests in Unicode system
    Check for runtime errors
    Look for sematic errors
    Check ABAP list layout with former double byte characters
    Use UCCHECK to analyze your applications:
    Remove errors
    Inspect statically not analyzable places (optional)
    Untyped field symbols
    Offset with variable length
    Generic access to database tables
    Set unicode program attribute
    using UCCHECK or SE38 / SE24 / ...
    Do additional checks with SLIN (e.g. matching of actual and formal parameters in function modules)
    Refer following links for more details.
    http://service.sap.com/unicode@sap
    http://www.unicode.org
    Hope this will help you, do revert if you need any more info.
    Best Regards,
    Sachin.

  • UCCHECK error:  TRANSLATE... CODEPAGE/NUMBER FORMAT is not allowed

    Hi ,
    I am getting error " TRANSLATE... CODEPAGE/NUMBER FORMAT is not allowed" while doing UCCHECK activity.
    Existing code is
      DATA: BEGIN OF BIN_TAB OCCURS 500,  
            SATZ(1500)  TYPE C,
          END OF BIN_TAB.
       translate bin_tab from code page '1100'.
    I am getting this error for above statement.
    Class  CL_ABAP_CONV_IN_CE should be used but not sure about the syntax.
    Please suggest how to resolve it ?
    Thanks:
    Anugrah

    Please refer to below link:
    http://wiki.scn.sap.com/wiki/display/ABAP/CL_ABAP_CONV_IN_CE
    Thanks,
    Sunny

  • UCCheck Showing error with XSL statement

    We are preparing to convert to Unicode and my XSL scripts are failing in UCCheck.  It appears my XSLT script (Z_EBPP_FINAL_OUTPUT_CSV) is fine, but the SAP created code behind it is failing (Z_EBPP_FINAL_OUTPUT_CSV=======XT) on the first line "<xsl:transform version="1.0"
    with an error message = "Statement "<XSL" is not defined. Check your spelling."
    Has anyone experienced this problem before?  If so, how did you fix it?
    Thanks,
    Ken Kammer
    The Reynolds and Reynolds Co.

    Here is the code that is causing the problem:  Unicode is saying the first line is in error in the SAP generated code from the XSLT.
    <xsl:transform version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlns:sapxsl="http://www.sap.com/sapxsl"
      xmlns:asx="http://www.sap.com/abapxml"
    >
    <xsl:output encoding="iso-8859-1" method="text"/>
    <xsl:strip-space elements="*"/>
    <xsl:template match="asx:abap/asx:values">
    <xsl:text>Bill To,</xsl:text>
    <xsl:apply-templates select="SOURCE/_-1BEA_-S_CRMB_BDH_WRK/PAYER"/>,<xsl:text/>
    <xsl:apply-templates select="ADDINFO/PAYERNAME"/><xsl:text>
    </xsl:text>
    <xsl:text>Invoice No.,</xsl:text>
    <xsl:apply-templates select="SOURCE/_-1BEA_-S_CRMB_BDH_WRK/HEADNO_EXT"/><xsl:text>
    </xsl:text>
    <xsl:text>Date,</xsl:text>
    <xsl:apply-templates select="SOURCE/_-1BEA_-S_CRMB_BDH_WRK/BILL_DATE"/><xsl:text>
    </xsl:text>
    <xsl:apply-templates select="INVOICEITEMS"/>
    </xsl:template>
    <xsl:template match="INVOICEITEMS">
    <xsl:text>Ship To,Name,Line #,Ref #,Order Number, Quantity,Description,Customer Price,Extended Price,Allowance Amount,Net Price
    </xsl:text>
    <xsl:apply-templates select="INVOICEITEM/SOURCE"/>
    </xsl:template>
    <xsl:template match="INVOICEITEM/SOURCE">
    <xsl:apply-templates select="ZZSHIP_TO_CUST"/>,<xsl:text/>
    <xsl:apply-templates select="ZZSHIP_TO_CUST_NAME"/>,<xsl:text/>
    <xsl:apply-templates select="ITEMNO_EXT"/>,<xsl:text/>
    <xsl:apply-templates select="ZZCONTRACT"/>,<xsl:text/>
    <xsl:apply-templates select="ZZLEGACY_ORDER"/>,<xsl:text/>
    <xsl:apply-templates select="ZZQTY_SHIPPED"/>,<xsl:text/>
    <xsl:text>"</xsl:text>
    <xsl:apply-templates select="ZZPROD_DESC"/>",<xsl:text/>
    <xsl:apply-templates select="ZZUNIT_PRICE"/>,<xsl:text/>
    <xsl:apply-templates select="ZZGROSS_PRICE"/>,<xsl:text/>
    <xsl:apply-templates select="ZZDISC_AMOUNT"/>,<xsl:text/>
    <xsl:apply-templates select="NET_VALUE"/><xsl:text>
    </xsl:text>
    </xsl:template>
    <xsl:template match="ZZSHIP_TO_CUST|ZZSHIP_TO_CUST_NAME|ITEMNO_EXT|ZZCONTRACT|ZZLEGACY_ORDER|ZZPROD_DESC|PAYER|PAYERNAME|HEADNO_EXT|BILL_DATE">
    <!-- this is for string value nodes -->
    <xsl:value-of select="normalize-space(.)"/><xsl:text/>
    </xsl:template>

  • Problem in UCCHECK  (*kna1 = Kna1)

    Hi All,
    1) What is the meaning of  ABAP statement
    TABLES: *KNA1.
    2) What will happen if i execute ABAP statement
       *KNA1 = KNA1
    3) In UCCHECK t-code system is giveing me error in an object which contains the above statements, the error message is
    "OF KNA1" is not expected
    Pls can anyone brief on this 3 points
    Regard
    Anees

    Hi Sudheer,
    Thanks
    Ur answe was helpfull enough to solve my UCCHECK problem
    We solve the problem.
    Instead of *kna1 = Kna1
    we use corresponding  statement.
    Regard
    Anees

  • UCCHECK in 4.7

    Hi All,
    We are planning to upgrade from 4.7 to ECC 6.
    My requirement is to before going for upgrade to ECC 6.i need to check all CUSTOM programs for UNICODE compatiablity in 4.7. If any errors found i need to correct it in 4.7 itself and then go for ECC 6 upgrade.
    For doing this i find transactions UCCHECK, SAMT , Code Inspector
    I like to know whether we can do the UCCHECK in 4.7 itself?
    Thanks
    aRs

    HI
    in Upgrade from 4.7 to ECC 6.0, system will be the same only.
    only we use to compare previouse code (4.7 version) through version management and then we correct the program by replacing some obsolute function modules and adding encoding default to dataset statements... etc.
    and then will check the program in UCCHECK transaction, if there are errors, it will show you a list errors in the program to correct.
    thats all we use to normally.
    regards,
    munvar.

  • Using UCCHECK during upgrade to ECC 6.0.

    We are upgrading from 4.6B to ECC 6.0.   I am running UCCHECK to flag unicode errors.  We are in the process of correcting these.   We are assuming the warning can be ignored and are not mandatory to address.     Is his a valid assumption.
    thx,, J

    Hi Markus,
    Thanks for your interest.
    The main problem I have is (I think) because this is an upgrade and all phase logs are under /usr/sap/put/log. Each phase has its own log file name that is known because the Upgrade Server web page has a phase list where it specifies those names so the problem should be explained there.
    The only error I found in the logs for this phase is:
    2 ETQ092 Package queue calculation failed, rc = "4", reason = "Calculate the queue part for EA-FINSERV rel.600 with target SP SAPKGPFD12 (level"
    no other logs at that date and time mentions anything about support packages.
    I looked at the logs under source release 4.6C but there is nothing on that date so I guess that it is doing all process with the upgrade executables.
    What we did was to keep going using stack 11 that worked just fine as before but this problem is a black box in this process. Same happened before in a test upgrade and now we don´t get any clue either (in the logs).
    Prepare only said that there was a calculation problem and that was it, no help, no clue, so we are blind here.
    I don´t really want to create an OSS because in this enterprise the support service is Max Attention but notes takes the same time as in any other company with SAP licenses. About 3 weeks ago we had a problem and created an OSS note as High and we only got answers (and what kind of answers) every 24 hours and the problem was solved (4 days later) here doing all kind of tricks known by abap developers.
    We are going to install stack 12 as a post upgrade process that is not exactly the best for us but we are in a tight schedule and are already upgrading Quality system only have one more chance to do upgrade tests in a production test system.

  • UCCHECK ASSIGN 019 error

    Hi,
    In UCCHECK, for below code, I am getting error "You cannot use ASSIGN f+offset. Always use an explicit length (or '*')."
    DATA: BEGIN OF ITAB OCCURS 1,
          FIELD(80),
          END OF ITAB.
    DATA : LV_INDEX LIKE SY-INDEX.
    FIELD-SYMBOLS: <SCR>.
    ASSIGN ITAB+LV_INDEX  TO <SCR>.
    Can  somebody please explain the issue and how to fix it?
    Thanks,
    Yogita

    Hi Yogita,
    You need to specify the offset length explicitly in case of unicode system.
    Check this code.
    DATA: BEGIN OF ITAB OCCURS 1,
    FIELD(80),
    END OF ITAB.
    DATA : LV_INDEX LIKE SY-INDEX.
    FIELD-SYMBOLS: <SCR>.
    <b>ASSIGN ITAB+LV_INDEX(80) TO <SCR>.</b>
    Check this link for limitations of ASSIGN in unicode system
    http://help.sap.com/saphelp_nw04/helpdata/en/79/c55470b3dc11d5993800508b6b8b11/content.htm
    Thanks,
    Vinay

  • "the current system is not the original system" in uccheck

    Hi  Friends,
    I get a message during the unicode conversion. Can u help me how to rectify this error.And also would be grateful if u can given some links regarding this issue and why this error message is raised.
    "the current system is not the original system" in uccheck transaction of unicode conversion.
    thank you
    chandra

    Do you still need help on this?
    Please refer to SAP notes that  can provide some hints
    #997198     UCCHECK: The current system is not the original System
    #963311     UCCHECK reports errors on XSLT sources
    cheers,
    Vincent

Maybe you are looking for