The Wonder tool –Technical upgrade made easier
Having worked on an upgrade project, I have always wondered whether a tool can be designed which would help us do the activities involved in the process more efficiently and quickly.Infact this might just be a reality, because the concept for the tool is indeed practical especially for activities like UCCHECK compliance.
How to go about it: Since in the phase of the UCCHECK compliance , i.e. the activity of making the objects unicode compatible (upgrade from 4.6C or older version to ECC 6.0) comprises of a set of errors which have to be removed to make the code unicode compatible. AS these set of errors are more or less repeated and can be categorized easily.
Steps that would be involved:
- To scan the program/object that has to be made Unicode compatible. It might be multiple programs at a time.
For this a good logic would be to use the SCAN ABAP-SOURCE statement to scan the program content and break down into tokens and statements to be altered further.
2. Categorize the Error types: The Unicode errors usually can be categorized in 2 types:
Single line changes: (FIND AND REPLACE): These would ideally be the errors which need minor replacement and syntax change according to new syntaxes. Some of the errors which would fall under this category would be like:
Open dataset – (addition of “ENCODING DEFAULT’ clause)
Describe field – (addition of “in CHARACTER MODE” or “IN BYTE MODE”)
Simple Replacements like
Since usage of ‘><’ is obsolete, it has to be replaced by NE.
‘=>’ should be replaced by GE.
‘=<’ should be replaced by LE.
And Few others.
(Although these are not mandatory replacements, but its always better to remove such obsolete syntaxes.)
All these can be easily removed with the help of the tool, since they just require the “FIND AND REPLACE” logic with minor modifications.It would be easy to track them because tehy have alraedy been scanned ( in step 1)
Contextual changes: (Replacement of obsolete FM’s): These changes require more than one line changes and the following errors would fall into this category:( As these have to be replaced by their latest counterparts while upgrading to newer version)
OBSOLETE FM’s like:
And lot others which have been used in the older version should be replaced using different logics for each one of them, as already mentioned these all will be purely contextual.
How to fix them: Since these changes are purely dependent on the changes to be made according to their new version counterparts.
So obviously a different logic would be applied for each one of them, as per the requirement.
Hence the chunk of the work to be done would be effectively done by this tool, rather than putting manual effort for several days.
But this has to be tested rigorously so as to make sure it works as desired.
Hopefully we would be able to make such a tool in near future.