Short Dumps while importing SAPKB70111

[Matt_Fraser]

I'm in the middle of importing Support Stack 13 for NetWeaver 7.01 (ABAP) and have hit a brick wall.  During the import of Basis SP 11 (we are going from Stack 10 to Stack 13, so Basis SPs 11, 12, and 13 are included in the queue) I encountered a fairly typical error, namely that an object was marked as repaired in my system.  Normally in this circumstance I would use SE10 to research any transports that might have contained the object, to know a bit about its history and ensure any such transports are released, and SE03 to reset the repair flag on the object, after which I would repeat the queue import.

However, when attempting to use either of these transactions, and many others besides, I got various short dumps referring to a syntax error in SAPLSDSD showing that various Types are unknown or don't exist:  BADI_SECLOG_F4, BADI_ALV_GRID, and BADI_TREE.

It turns out this is a known error with Basis SP 11 for 7.01 (and also Basis SP 26 for 7.00 or SP 10 for 7.02), well described in Note 1700109 (System Dumps Due to New Inactive ALV BAdI Spots).  The basic problem is that workbench transactions like SE10, etc, are not properly functional during the upgrade or OCS import during or after the Main Import and before the XPRA phase, and so if you have other problems with the import (like a repair flag that needs to be reset), you have a bit of an issue.  The Note provides a workaround in the form of a program which will activate the required ALV BAdI spots and thus allow you to use your workbench tools to get on with it.  The Note even states that SNOTE is not likely to work while in the middle of an OCS import and so you'll have to use SE38 to create a temporary Z version of the program.  All well and good.

There's just one problem.  I am also getting a short dump in SE38, unlike the ones described in the Note, so I can't even create the program to fix the BAdI error.

It looks like SE38 (and SE37) want to call a program called SAPLSGSUB_SERVICES, and in Include IF_SWF_RUN_WIM_INTERNAL a syntax error is encountered for "Type SWFTDECIALTS is unknown".

I haven't found any Note or SDN discussion that references this situation, and I'm uncertain how to proceed (short of restoring from a backup, fixing these now-known errors in advance, and then restarting the queue import from scratch).  I tried going into SE80 to see if I could find this Type or Class Interface and perhaps regenerate it, but SE80 is suffering from the same short dumps as the other workbench tools.

I'm open to suggestions.

Best regards,

Matt

[Matt_Fraser · Accepted solution]

Some updates to this ongoing saga:

First off, I seem to have stumped SAP support (yes, I do have a Customer Message open with them), but hopefully between them and me both working it we'll come up with something.

Meanwhile, it looks like the dump in SE38 that I'm getting in IF_SWF_RUN_WIM_INTERNAL is perhaps caused by Note 1648822.  This Note was included in Basis SP11 and then updated again in Basis SP 13.  Because my import stopped duing the Main Import of Basis SP11, so I have the DDIC changes from SP11 and SP13 but the code changes only from SP11, it looks like I have part of the code change for this Interface, but not all of it.  I can see two new Methods, SET_DECISION_ALTERNATIVES and GET_DECISION_ALTERNATIVES, that don't exist in my SP10 (downstream) systems, and which reference the Type SWFTDECIALTS.  However, the Type doesn't yet exist in the Interface, although in a different system already on a higher Basis release (7.02) and SP level, I can see the code for defining the Type.  Of course, SE24 isn't allowing me to enter this code.  I'm not sure why this workflow-related piece of code is being called whenever I try to run SE38, but it is, and that's the problem.

However, addressing the original problem of not being able to run SE03 due to the missing ALV BAdI enhancement spots, I confirmed in SE18 that the spots are inconsistent (N-versions exist), and the error code from trying to display one of them led me eventually to Note 1483283.  This Note talked about different inactive enhancement spots, but nevertheless the procedure outlined for pre-generating them seemed like it might be applicable.

So, using SE24 again, I executed Class CL_ENH_BADI_PREGENERATION, Method BADI_PREGENERATION, and ran it once for each of the three spots (SECLOG_ALV_GRID, SECLOG_F4, and SECLOG_TREE).  It appears to have generated all three successfully, which is confirmed in SE18.  Sure enough, I am now able to run SE03 and thus reset the repair flag that originally stopped my queue import.

I have a new problem, however.  When restarting the queue import in SPAM I am getting a new short dump:  SYNTAX_ERROR in program SAPLSUU1:  "The type or row type of USRXX_DELETE cannot be converted to table U SR07 in the key part cannot be converted to table USR07 in the key part" (sic).  The error is triggered in Program SAPLSPAM, Include LSPAMF01, Form CHECK_DDIC_USER.

I'm researching this error now, but perhaps someone else has encountered this?

[former_member272420 · Accepted solution]

Hi Matt,

I am facing the saem problem when restarting SPAM (after an DB Log Full stuck )

Shortdump: Syntax error in program "SAPLSUU1 ". ->

The following syntax error occurred in program "SAPLSUU1 " in include "LSUU1U09

" in

line 262:

"The type or row type of "USRXX_DELETE" cannot be converted to table "U"

"SR07" in the key part cannot be converted to table "USR07" in the key "

"part,"

Do you already have an solution?

[former_member272420 · Accepted solution]

Found note, solved my problem:

Note 1597765 - Known problems with
Support Packages in SAP NW 7.31 AS ABAP

• 
  SAPKB73105

           Symptom: If the import of the Support Package SAPKB73105
terminates in the phase IMPORT_PROPER, it cannot be continued in the Support
Package Manager because this leads to a syntax error in SAPLSUU1:
The row
type from "USRXX_DELETE" cannot be converted to the table "USR07" in the key
part.

Solution: To avoid the error, the DDIC user check can be
deactivated in the settings of the Support Package Manager (option "Check for
active DDIC user"). This is possible as of SPAM/SAINT Version 0043.
If the
error has already occurred, the deactivation can take place only in the
configuration table PATCHECK.  For the entries with CHECK_NAME =
"DDIC_USER_REQ", set the value of the field ACTIVE to " " (space/blank
character). Then you can continue importing the Support Package queue.
After
you import the Support Package queue, you can activate the check again in the
settings.

[Matt_Fraser · Accepted solution]

Hi Sjoerd,

Yes, I found this Note, and the equivalent one for Basis 7.0x that is applicable to me, 822379, almost right after I wrote my last bit above.  I am on SPAM version 49, the latest available at the time I set up my queue in mopz a few days before, and I found that even though the error had already occurred, I was able to use Extras... Settings... in SPAM to turn off the "Check for active DDIC user" (I didn't have to resort to manually editing table PATCHECK), and this allowed me to proceed with my queue import.

So far, so good.  I held off on writing up the solution here until my import was complete and I had confirmed that no more errors persisted afterwards (I'm still wrapping up the modification adjustments in SPAU right now).  However, I can confirm this morning that SE38 is now working correctly and that all looks good.

So, for others who may read this with similar problems, here's a quick summary of the solution (discussed in more detail above):

To enable workbench tools (SE03, SE10, etc) to work while stuck in the IMPORT_PROPER (Main Import) phase of importing SAPKB70111 (or equivalent in other Basis releases), if you are getting dumps in SAPLSDSD referring to Types BADI_SECLOG_F4, BADI_ALV_GRID, or BADI_TREE not existing or being unknown, the basic solution is Note 1700109.

If, however, when attempting to apply the changes from Note 1700109 you find other short dumps in SE38 and/or SE37 that prevent you from carrying out the instructions, i.e. a syntax error in IF_SWF_RUN_WIM_INTERNAL referring to Type SWFTDECIALTS being unknown, the solution is:

1. Execute transaction SE24.
2. For Object type enter Class CL_ENH_BADI_PREGENERATION and hit Test (F8).
3. Select Method BADI_PREGENERATION and hit Execute method.
4. For ENHSPOTNAME enter BADI_SECLOG_F4 and hit Execute (F8).
5. Repeat for Enhancement Spots BADI_ALV_GRID and BADI_TREE.

This procedure is suggested in Note 1483283, and Note 1700109 may soon be updated to include it, based upon my Customer Message.  You should now be able to proceed with whatever you need to do to fix things and continue your queue import or upgrade.

If, however, your import queue includes SAPKB70113 (or equivalent for other Basis releases), you may get new short dumps when trying to restart the queue, a syntax error in SAPLSUU1 referring to a row type of USRXX_DELETE which cannot be converted to table USR07.  The solution to this is in Note 822379 (or equivalent Note for other Basis releases), and basically is:

1. Restart transaction SPAM.
2. Select Extras... Settings...
3. Under Checks during import DESELECT Check for active DDIC user.
4. Save the setting and continue the queue import.
5. Once the import is successfully finished, remember to go back and put this setting back the way it was.
6. If you aren't on a high enough SPAM version, you may not be able to do this once the error has already occurred.  In this case, Note 822379 refers to a workaround involving manually editing table PATCHECK.  I didn't have to do this, however, with SPAM version 49.

This should solve everything, and the import should continue fine.

Best regards,

Matt

[Former Member · Accepted solution]

Hi Matt.

I've got a similar problema like you. When importing 7.01 BASIS support packages from 11 to 14 with tx. SPAM in downtime-minimized, in phase 3 running in batch, when executing IMPORT_PROPER were generated hundreds of dumps and when trying to logon in client 000 with DDIC user I got the same dump as you.:

Sintax error in program "CL_ITEM_TREE_CONTROL====CP". The type "BADI TREE" is unknown.

Also when trying to execute tx SE38 in order to create report ZENH_REPAIR_ALV_SPOT as says SAP NOTE 1700109, compiling tx SE38 generates a new dump:

Sintax error in program "SAPLSTRD". The field "GT_CONFIRMED_MESSAGES" is unknown.

When trying to implement your solution, I got the same compilation error as tx. SE24 also uses the report "SAPLSTRD". So I cannot execute txs SA38 / SE38 / SE27 / SE24 / SE80.

So, do you know some transaction that doesn't use report "SAPLDTRD" o the way to solve de "SAPLDTRF" syntax error?.

We cannot also execute tx. SPAM. We also realices, looking at tx. ST22 tan, while executing activity 'DDIC_ACTIVATION' were generated dozens of

'DDIC_TYPE_INCONSISTENCY' dumps, and in activity 'IMPORT_PROPER' hundreds of 'SINTAX_ERROR' dump, but the downtime phase job didn't abort.

Thanxs in advance for your help.

Best regards.

[Matt_Fraser · Accepted solution]

Hi Sergio,

It looks like you've run into a similar yet different issue than the one I had two years ago reported in this thread. Offhand, no, I don't know what you should do differently, if the procedure I outlined that worked for me isn't working for you. It seems the root is that SE24 worked for me, but it is dumping for you, so that's new/different.

My suggestion is to start a new thread, as a question, in this forum. You can refer/link to this discussion to show that you've tried these suggestions but are still having trouble. You're likely to get more people looking at the problem and helping you if you do this.

Cheers,

Matt