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