Skip to Content
Technical Articles

Touch or no touch, that’s the question.

An emergency transport of changed and potentially loaded objects into a running SAP system is always thrilling for the one pressing the button in STMS.

For SAP it is quite easy, they just tell not to do so.

So I thought to start a blog and log import problems. Maybe it will help others a little to reduce the thrill.

As this is always kernel dependent, I add the kernel. And if you contribute your fails or successes, please also add the kernel version of your system.

 

Kernel 745 / 753

Import of public components DDIC (e.g. Tables/Structures) , public class components (CPUB) / Interfaces are risky and can result in a dumps of like 

LOAD_PROGRAM_CLASS_MISMATCH, LOAD_PROGRAM_INTF_MISMATCH, LOAD_TEXTPOOL_LOST

Import of DDIC translations lead to a generation of dependent DDIC objects and therefore to new timestamps

Import of pure code LIMU REPS, LIMU METH, LIMU FUNC seem to work.

Major import failures:

A (new) implicit enhancement in the source code of a SAP class lead to many short dumps.

Customizing transport FI validations (GGB0) led to failure in “Method Execution” ( generation of depending programs ). Since then we check the methods of the customizing object in transaction SOBJ.

 

 

 

 

 

 

3 Comments
You must be Logged on to comment or reply to a post.
  • Hello Jürgen,

     

    Thanks for sharing. I believe it is also valid to share solution to mentioned errors, once available.

    For mismatch related ones, we can find the summary on how to solve them in KBA 2169739.

    Cheers,
    Maurício

  • Hi Jürgen,

    I think that for OO-code only changes to the PUBLIC section are relevant, as you write. For non-OO code however, I think ANY change leads to a new version of the frame program, and therefore to MISMATCH dumps if during runtime it is found out that different versions are being used by different (also loaded) other frame programs.

    A funny thing that I noticed, is that when you load a class that has formerly been edited in the SE24 form-based editor, into the source-based editor or Eclipse, and pretty-print it, you change the FORMAT (although not the real content!) of the public section. So you also get the problems when importing into another system.

    And any header comment that you place above the PUBLIC section of classes in a source-based editor (SE24 or Eclipse) also counts as part of the public section. So if you add a line to the version history there, you have a change of the public section. (For this reason, our coding guideline demands the “header comment” for global classes to be written into the constructor.)

    One more thing: maybe you want to change the title of the blog so that it is easier found?

    Best regards,

    Edo

  • What about the protected section of a class and its subclasses, and even the private section if there are friend interfaces and classes. If one is changed, shouldn’t there be a recompile, isn’t there a risk also?