issues with upgrade

[Former Member]

Hi all,

can any one tell me what kind of changesto zprograms can be expected when we go for an upgrade from 4.6c to ECC 6.O WITH UNICODE

Thanks

Kajol

[Former Member]

Hi all,

can any one tell me what kind of changesto zprograms can be expected when we go for an upgrade from 4.6c to ECC 6.O WITH UNICODE

Thanks

Kajol

[RichHeilman]

Here are the issues that I am facing as I've just ran UCCHECK on all of our custom programs the other day.

First, any program which uses WS_UPLOAD or WS_DOWNLOAD will need to be changed to use the unicode compliant GUI_UPLOAD and GUI_DOWNLOAD, or the associated methods of the class CL_GUI_FRONTEND_SERVICES.

Also, and program using OPEN DATASET statements will need to be modify to include the ENCODING extenstion, you may simply be able to add ENCODING DEFAULT.

Plus there are a few other errors which will prevent the code from passing a syntax check.

Suggestion is to run transaction UCCHECK on all of your custom developments.

Regards,

RIch Heilman

[Former Member]

Hi Rich,

Apart from ws_upload, ws_download(obsolete FM'S) ,obsolete commands are there anythings that should be taken care of

,

I'm trying to get list of the things to get done when we move to ECC 6.0

Thanks

[RichHeilman]

There are new statements which replace older statements such as the FIND statement replaces the SEARCH statement, but again, you can't do any of these changes under you have your ECC 6.0 box. And also, the older statements will still work except for those that have changed syntacicly such as the OPEN DATASET statement.

Regards

Rich Heilman

[Former Member]

Hi,

I have on more question

i cannot have type i in an internal table when i am going for unicode right.

Say i have

data : begin of itab occurs o.

include structure ztable,

data : a type i,

end of itab.

this gives me an erro in ecc 6.00 right?

let me know if iam wrong

can you tell me what all i cannot have in the internal table

thanks

kajol

[RichHeilman]

I am not seeing any problem with it. Make sure that the 0 after the occurs is a ZERO, not an O and put a period after ZTABLE. If you were not allow to have type I in your internal table, there would be massive problems and a lot of work. There is no problem with it.

data : begin of itab occurs 0.
include structure ztable.
data : a type i,
end of itab.

But again, it is suggested to create internal tables like so.

TYPES : BEGIN OF ttab  .
        INCLUDE STRUCTURE ztable.
TYPES : a TYPE i,
        END OF ttab.

data: itab type table of ttab.
data: wa like line of itab.

Make sure to award points for any helpful answers that you might recieve. Thanks.

Regards,

RIch Heilman

[Former Member]

Hi ,

i siad we cannot have type i internal table because i was reading in some post saying that for unicode syntax everything in the internal table should be of character type and type i should be replaced by type n.

It was written by moderators too

let me know if iam wrong

TYPES : BEGIN OF ttab .

INCLUDE STRUCTURE ztable.

TYPES : a TYPE i,

END OF ttab.

data: itab type table of ttab.

data: wa like line of itab.

i awarded points to you all

thanks

kajol

[RichHeilman]

<i>i was reading in some post saying that for unicode syntax everything in the internal table should be of character type and type i should be replaced by type n.</i>

I do not think that is true. Now, I can see a problem if you are trying to move the entire row of the internal to another structure. Depending on the types of fieds in the row, and doing something as below, there could be some syntax errors(unicode errors) coming from this.

wa2 = wa1.

Regards,

Rich Heilman

[Former Member]

Hi,

1.Internal table with header line will not support in ECC 6.0 for that you need to create internal table and work area using TYPES.

2.Mostly you need to do some PATCH WORK for the STANDARD programmes.

Patch work in the sense for SPAU objects in Mysap is there any code written by client(INSERT {....END INSERT....}) this type of code u need to add in ECC 6.0 code....

3.Mostly you have to resolve EPC (Extended program check) errors.

In that you will find so many type of errors... Field attribute errors,Perform interface errors, Obsolete stetement errors, ... etc.

4.First thing you need to what are the SCOPE and OUT OF SCOPE in your upgradation.

5.If you find any FM obsolete ... You just press F1 on that Fmodule it will show which function module can useful instead of that obsolete one...

6.If they want UNI CODE compatiable .....

EX Report...

Go to the attributes of the report...

There you can c a check box to check UNICODE Errors...

You have to resolve these errors also...

After doing all these things you have to show 0 errors on CODE INSPECTOR for each and every object ...

Also please check this document on ABAP Obsolete.

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5ac31178-0701-0010-469a-b4d7fa27...

Regards,

Ferry Lianto

[RichHeilman]

<i>Internal table with header line will not support in ECC 6.0</i>

This is not true. Header lines will still work in ECC 6.0. They are not recommended as they are not supported in the OO context, which means that you can not use them in a class, but you can still use them in all other development objects. But again, it is recommend to discontinue the use of header lines.

Regards,

Rich Heilman

[Former Member]

Hi,

Rich, are you running uucheck in which version

Ferry ,Internal table with header line will not support in ECC 6.0 for that you need to create internal table and work area using TYPES.--- this is true for only OO PROGRAMING RIGHT?

Thanks

Kajol

[RichHeilman]

Kajol, yes, you must UCCHECK in the ECC 6.0. In our case, we now have a sandbox which was 46c, now upgraded to ECC 6.0. So I have started looking at what needs to be changed. So I'm running the UCCHECK in ECC 6.0. It simply does not exist in 46c.

Regards,

Rich Heilman

[Former Member]

hi

good

you can get all the details if you go through the ECC6.0 release note.

TakeCAre

mrutyun^

[Former Member]

Hi,

The major changes you will face related to SYNTAX, this u can check for a particular program using Tcode : UCCHECK .It will tell you the line with the required modification .

As in upgrade, screen sequences are changed, you may face majr changes in the BDC programs .

Thanx .

[Former Member]

hi,

whe upgrading to higher version :

1> many of the finction modeules have gone obsolete like ws_download, ws_upload and many more

2>some of the transaction fields may have got mandatory or would have gone missing, and some fields would have been added.

3>many of the tables,views would have gone missing

4>the standard programs like subroutine pools and report programs may not exist or the selection screen may have got changed.

5>as you are moving to unicode system there may many unicode ussies like in the split,concatenate,overlay and translate opns it can be only performed on character datatypes(c,n,d,t) earlier it allowed to perform on integer data types also

[Former Member]

hi

in additon to my earlier reply

uccheck tcode is present only in unicode version

and regarding internal tables u declare it in this way,

DATA: itab1 LIKE STANDARD TABLE OF wa1 WITH HEADER LINE.

[RichHeilman]

<i>uccheck tcode is present only in unicode version</i>

This is not true also. We are currently running a non-unicode system and the UCCHECK transaction is available.

Understand that if you are a single code-page system, that you do not NEED to go unicode, but it is recommended. Also, if you don't go unicode, you are not forced to make you code unicode compliant and you can actually turn of the unicode compliant checking in the ABAP editor.

Again, it is strongly recommended that you go unicode and while upgrading, make all of your custom programs unicode compliant. At some point in time, you will need to go unicode(it is not going away), there is no escaping it.

Regards,

Rich Heilman

[Former Member]

Hi Rich,

When you say this,

uccheck tcode is present only in unicode version

This is not true also. We are currently running a non-unicode system and the UCCHECK transaction is available.

but it has 630 complaint system right.

even though 4.6c is non unicode system UUCHECK is not available

what exactly you mean by non unicode system in the above senetence

thanks

Kajol

[RichHeilman]

Actually, when you upgrade from 46c to ECC 6.0, you will be forced to go non-unicode initially. There is no way to do a unicode conversion on a 46c box, so you must first upgrade to ECC 6.0, then maybe a week later, do the unicode conversion. This is our plan. This is why when upgrading, you should just make your programs unicode compliant right from the start and set the "Unicode Check Active" in the program attributes. This way when you basis team does the unicode conversion, you don't have to worry about a thing. All is well(at least it should be).

Regards,

Rich Heilman

[Former Member]

Hi,

Rich is correct. They are not recommended to use hader lines as they are not supported in the OO context but it is still working in ECC 6.0..

Regards,

Ferry Lianto