Tried that one already.
No difference, old SUM in old dir (which I saved w/o making manuel "monkey biz" changes to it) won't start up anymore, due to error "[Error]: com.sap.security.core.server.secstorefs.NotFoundException: Could not find a record with key "J2EE/StandardSystem/Instances/array1/InstanceSidAdminUser/Password" in the store."
And I can't even try to import SPs in SPAM anymore, because system complaints about "update running via update manager" and wants me to finish SUM first - wich I couldn't even if the darn thing would start up again (UVERS mismatch).
I tried to run a new SUM to import the missing SPs via XML stack, but our SolMan refuses to calcualte the correct stack file for this inconsistent ERP system.
So I can't get a correct XML stack to import the missing SPs/Add-Ons via a new SUM run, I can#t import them manually, because either the system is still locked by (the old) SUM or you can only import SP Basis as of 7.4 via SUM anyway - and that damn SUM now won't start up because of a messed up password store.
Seriously folks, wtf is up with this messed up SUM bullsh1t ?!!
If SAP wants everyone and everything to rely on SUM now, at least they should ensure the damn thing doesn't fail that easily.
I mean *nobody* messed with that download dir or the XML file, and there were no errors during the import phase or the shadow build or execution steps.
So wtf did SUM complain that it didn't find what it was expecting to begin with - because it was SUM and SUM alone who build the damn thing?!!
There was no manual intervention here, no step was skipped, so what the heck went wrong?
And is there any chance to get out of this again?
If two+ weeks time would have been wasted on this, the whole project is at risk (and my job, too)
