Obsolete ABAP Statements from 2004s - what about your existing code-base?

Question

Hi
Note:  This is a question for someone that has a very deep understanding of the SAP compiler either through research or through actually working on the Netweaver Code stack
Since upgrading from 4.7 to ECC6 the ABAP compiler has become a lot stricter on the use of certain statements in the OO context.
For instance you're not allowed to use the statement LIKE, but in stead have to use TYPE and internal tables does not have an implicit header line, etc.
These restrictions are explained in greater detail [here:|http://help.sap.com/abapdocu/en/ABENABAP_OBJECTS_DIFF_TYPES_DATA.htm]
MY QUESTION:  To what extent does this restriction affect your existing code-base?. 
We have over a thousand "Classes" written since 1998 in OO as far as it was available at the time.  For the most part each class is its own include in SE38, with the class definition and implementation together in this include.
Up to now, we could successfully change and activate these classes as long as the main program was pre-existing in 4.7.  Now we are trying to use one of these older classes in a new main program for regression test purposes, and we are getting the following error: 
"Within classes and interfaces, you can only use "TYPE" to refer to ABAP Dictionary types (not "LIKE" or "STRUCTURE")."
This error is valid as per the current definition of the SAP language.
BUT I'm concerned about the confidence we can have that SAP will continue to interpret and execute existing code correctly.  So far it has, but I would like to know wheter that is by chance, or by design.

Answer 1

Hello Esti
Thank you for your explanation which shows that I misunderstood your question.
I would have expected that all of your syntactically incorrect coding would not be executed, irrespective of whether it is an old or a new program. My interpretation of this system behaviour is that the syntax check appears to be release-dependent.
A possible way to check this would be to manipulate the TRDIR entry for one of your old programs. You will find a field LEVL with the following meaning:
DE RDIR_LEVL
Short Text
     Level
Definition
     System release under which the ABAP/4 program was created or last
     changed.
Another way would be to copy an old program to a new Z-program which should fail in the syntax check. Check again if you find any significant difference in their TRDIR entries.
Coming back to you question and the remark by Dion I am convinced that one of the biggest threats for each and every SAP customer is custom coding of poor quality, i.e.
"spaghetti" coding instead of structured programming
incomprehensible coding (at least for the developers who did NOT create the program)
low transparency resulting in high efforts to enhance or improve the coding
In your case: the possible breakdown of your coding depending on unknown external factors
Given the huge amount of coding that is affected from these unknown external factors I would classify your situation as "high risk" which demands rather quick actions. How could you communicate this to your management team?
Here are two possible suggestions:
(1) It is possible that your entire custom coding may be no longer executable after a SAP release upgrade. Thus, the currenct coding base may prevent one of the next upgrades.
I guess this is not yet impressive enough for a manager because usually a SAP customer is not forced to upgrade its SAP system in order to get new functionalities which are required for legal reasons.
(1.a) It is possible that your entire custom coding may no longer be executable after importing ABA and/or BASIS hot packages.
Given the fact that we need to import such packages quite frequently and sometimes they are mandatory (I think especially of SAP-HR systems) then I would be scared as a manager.
(2) Assuming that most of your Z-reports are started via Z-transactions and perhaps you are lucky and you have specific roles containing these Z-transactions then you may ask your management team to do a simulation of coding breakdown: remove the role assignments for a couple of users and see what happens.
(2.a) As an alternative you may try to lock Z-transactions via SM01 and again check for the user reactions.
If your managment team is still not impressed then I would set up a document with the following contents:
Explain the problems of the old coding base and why you could not anticipate future changes of the ABAP syntax check
Describe the possible scenario if the custom coding no longer works after an upgrade or hot package import
Describe the required actions to make your custom coding compatible to the latest ABAP release
Most important: urge your management team to sign this document. If one day your custom coding breaks and they are looking for somebody to blame you just take this document out from the bottom of the deck
Regards
  Uwe