ECC6 Upgrade stuck in Phase "Postprocessing"

[former_member1012268]

Hello World,

I am in a very tight jiffy here.

In preparation for the test upgrade of an ancient ECC6 system to xxx, we copied the Quality Assurance system of our ERP/ECC landscape to an isolated sandbox system (also named Q01).

Source System Version:

EHP5 FOR SAP ERP 6.0

SAP ECC 6.0

SAP ERP 6.0

SAP EHP2 FOR SAP NETWEAVER 7.0

SAP PORTF AND PROJ MGMT 5.0

Target System Version:

EHP7 FOR SAP

ERP 6.0 SAP

ERP 6.0 SAP NETWEAVER 7.4

SAP PORTF AND PROJ MGMT 5.0

We used MOPZ from a Solution Manager with a new release level (7.x and most recent SP package stack), so I trusted the XML file that it calculated for us.

A co-worker of mine took care of the actual download, because we have certain bandwidth limitations to combat at the office.

I had SUM run over the flat dir, with all the SAR Archives in it, and it didn't complain that it couldn't find certain, required target packages.

So I proceeded with the upgrade and besides some minor hickups with locked transports and modified SAP tables, it went through fine until we reached step 'Postprocessing".

Then SUM suddenly complained about mismatches in table UVERS, stating that it didn't find the version numbers it expected.

And indeed, when I loaded the Stack XML file in SAINt, it shows that it has, for at least six modules, the correct target releases specified, but complained that it could not safely finish the queue, because it was "missing support packages".

I was baffled to say the least, but managed to download all missing/required packages by hand and extracted them into the EPS-Inbox.

But now I got the problem that as of 7.4 "the Support Package Update to SAP NetWeaver AS ABAP 7.40 SP02, SP05 or to a higher SP where the update includes SP05 (e.g. from SP04 to SP06) is only possible with the SUM Tool" (SAP Note 1795865).

So I am stuck between a rock and a hard place, SUM won't continue and release the system, because it insists that UVERS isn't consistent with what it now expects to be in the system.

But I can't import those SPs manually, because all depends on "AS_ABAP", which can now only be imported via SUM, which is stuck/hang up on table UVERS.

I am already a week behind schedule on this one, so any real help here is truly appreciated!

Thanks in advance

                            Donald

[former_member182657 · Accepted solution]

Hi,

Give a complete restart to system and start the SUM again and retry the phase again.At the error stage resend the error log files .

Regards,

Gaurav

[former_member1012268 · Accepted solution]

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)

[Reagan · Accepted solution]

Stop the SUM completely.

If there are some SUM processes running then terminate them

cd /mnt/sapcd/RMF/SUM/SUM/sdt/data/variables

mv JUP.J2EE.DataModel.xml JUP.J2EE.DataModel.xml.BACKED

Restart SUM and see if that helps.

If that doesn't help then rename .sdt_keystore and .sdt_storage files present at  /mnt/sapcd/RMF/SUM/SUM/sdt and restart SUM

RB

[former_member1012268 · Accepted solution]

Thanks man, you are a miracle worker and a life saver.

cd /mnt/sapcd/RMF/SUM/SUM/sdt/data/variables
mv JUP.J2EE.DataModel.xml JUP.J2EE.DataModel.xml.BACKED

That one solved at least this foolish password problem for me (seriously, who the heck is SAP trying to protect with such a fault ridden procedure?)

Now SUM starts up again and I am back to the PostProcessing problem and table UVERS.

Thanks man, seriously!!

[Reagan · Accepted solution]

Now what is the exact error you have in the SUM console ?

Could you provide me the error screen shot from SUM ?

Did the system start up properly after the downtime phase ?

Could you provide the kernel used by the system now ?

su - sidadm

sapcontrol -nr 00 -function GetVersionInfo

Note: Replace 00 with the right system number.

RB

[former_member1012268 · Accepted solution]

The error message is:

> Repeat Phase MAIN_POSTP/SUCCHK_END to continue at the point stopped:

> Last error code set: Release of SAP_ABA was not updated in the database ('702' &lt; '740'<br/>

> Release of SAP_APPL was not updated in the database ('605' &lt; '617'<br/>

> Release of SAP_BW was not updated in the database ('702' &lt; '740'

Which appears to be correct, when checked in SPAM.

I also verified that all the SPs and Saint-Add-Ons are "imported" in the system, just not applied (why is besides me, SUM didn't throw any errors related to this during the upgrade).

Now I am stuck between a rock and a hard place, even so I managed to "mess with table UVERS" (no worry, I made a backup of it) to unlock SPAM & SAINT, I can't import the Basis SPs w/o SUM as of 7.4 and SUM wants an XML stack file, which I seem unable to calculate in SolMan for our "messed up" system.

The peasants are getting restless by now and official SAP Support is nowhere to be seen on this (hey, its "just" our QA system, right?!).

***************************************************************************************************************

sapq01:q01adm 52> sapcontrol -nr 10 -function GetVersionInfo

30.07.2014 15:03:59

GetVersionInfo

OK

Filename, VersionInfo, Time

/usr/sap/Q01/DVEBMGS10/exe/sapstartsrv, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:59:12

/usr/sap/Q01/DVEBMGS10/exe/disp+work, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 12:02:42

/usr/sap/Q01/DVEBMGS10/exe/gwrd, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:49

/usr/sap/Q01/DVEBMGS10/exe/msg_server, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:35

/usr/sap/Q01/DVEBMGS10/exe/dboraslib.so, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:21

/usr/sap/Q01/DVEBMGS10/exe/dbmssslib.so, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:21

/usr/sap/Q01/DVEBMGS10/exe/dbdb2slib.so, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:20

/usr/sap/Q01/DVEBMGS10/exe/dbdb4slib.so, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:59:07

/usr/sap/Q01/DVEBMGS10/exe/dbdb6slib.so, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:20

/usr/sap/Q01/DVEBMGS10/exe/dbsybslib.so, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:21

/usr/sap/Q01/DVEBMGS10/exe/enserver, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:37

/usr/sap/Q01/DVEBMGS10/exe/icman, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:50

/usr/sap/Q01/DVEBMGS10/exe/sapwebdisp, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:49

/usr/sap/Q01/DVEBMGS10/exe/jcontrol, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:52:12

/usr/sap/Q01/DVEBMGS10/exe/jlaunch, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:55:53

/usr/sap/Q01/DVEBMGS10/exe/jstart, 741, patch 26, changelist 1484266, RKS compatibility level 0, opt (Mar 21 2014, 11:51:46), linuxx86_64, 2014 03 21 11:59:02

sapq01:q01adm 53>

[divyanshu_srivastava3 · Accepted solution]

As this is your test system, I would say go for a restore.

Last error code set: Release of SAP_ABA was not updated in the database ('702' &lt; '740'<br/>
> Release of SAP_APPL was not updated in the database ('605' &lt; '617'<br/>
> Release of SAP_BW was not updated in the database ('702' &lt; '740'

Now, why the XML was not generated correctly  ?

Courtesy - manual updates and no resync of LDMB and SLD.

Correct this - regenerate XML - match comp vers with UVERS.

When all fine, go for an update.

We do on test to face such issue and correct them before going on real systems.

Divyanshu

[former_member1012268 · Accepted solution]

Then I am out of a job.

I had to rely on a jack-ass SM setup for the MOPZ calculations, that those were the requirements, no direct SolMan access for ourselves.

If I got to restart this thing from scratch, I'm done here.

Is there no chance at tall to get those damn SPs applied?

[divyanshu_srivastava3 · Accepted solution]

Anything is possible, if we can approach SAP for this.

As far as I have seen, solutions are there for such issues.

Just a weird idea - can you backup UVERS and modify what SUM is looking for ? Once system is out of SUM's scope, restore the tables and re-apply the patches ?

Or maybe, edit the XML with the version of UVERS and restart this phase

Divyanshu

[Reagan · Accepted solution]

It appears to me that there is an inconsistency with the UVERS and the CVERS tables (I might be wrong). How does the CVERS table looks now ?

If possible attach the CVERSDUMP.SAV, CVERSDUMP.TMP and the DBINFO.LOG log files from the log directory.

Regards

RB

[former_member1012268 · Accepted solution]

You are right about the mismatch between CVERS und UVERS.

Both look completely different in version numbers - with the version entries in UVERS being higher than those in CVERS.

Any way to get out of this?

[former_member1012268 · Accepted solution]

Here are the Pastebin Links:

CSVERSDUMP.SAV

http://pastebin.com/download.php?i=Mqg2bMxP

CSVERSDUMP.TMP

http://pastebin.com/download.php?i=dJwBTkLW

DBINFO.LOG

http://pastebin.com/download.php?i=VqtNnvZj

[former_member1012268 · Accepted solution]

What XML file and how *exactly* (please) do I "modify UVERS"?

Do I just copy CVERS over UVERS or which fields am I supposed to change to what?

[divyanshu_srivastava3 · Accepted solution]

you can try with copying contents of CVERS on UVERS.

It's a stupid idea, but then you can give it a try if nothing is working.

** please backup UVERS

[former_member1012268 · Accepted solution]

Changing the values for field "NEWRELEASE" in UVERS for the corresponding components didn't do a thing.

I still get the exact same error msg - so wherever SUM gets his comparison values form, its not UVERS vs. CVERS

[Reagan · Accepted solution]

The problem you have here is with the inconsistent CVERS and UVERS tables. If you see the UVERS table the components reflect the EHP7 component level. I will not suggest modifying version tables. As the upgrade is done on the quality system you should consult with SAP before you modify anything. It is possible that the upgrade went well but the tables were not updated with the correct information. I suggest you to call the SAP helpline and ask them to speed up the OSS message. Possibly a workaround will be provided by them instead of starting the upgrade from scratch.

[former_member1012268 · Accepted solution]

OK, that worked (maybe?)

I had to change the values in CVERS, to match what SUM was expecting.

Problem is that before that change, SPAM matched the content of CVERS to the point.

So now I am stuck with the unpleasant situation where CVERS and SPAM might no longer match up (or does SPAM just blindly trust what is in CVERS anyway?)

WHERE DOES SPAM GET ITS PATCH LEVEL INFO FROM???

Upgrade is now finishing, and I wonder how usable that system will be afterwards ...

Those devs are going to crucify me if its all messed up 😞

That happens if you have to trust somebody else's SolMan setup, beats me why SUM didn't catch it sooner.

[former_member1012268 · Accepted solution]

I had to do *something* here or call off the whole thing.

Please see my above post, and if you got some helpful ideas how to verify if I messed up by changing CVERS, I am all ears.

You wouldn't happen to know where SPAM retrieves its version info from?

I hope there is another place in SAP where that is stored, so that I can check if CVERS is correct now, or not.

[former_member1012268 · Accepted solution]

PS: SAP Support replied 2 times in 3 days on this(!!)

[divyanshu_srivastava3 · Accepted solution]

Have a look at these tables, surely one of them should be used for SPAM

CVERS	Release Status of Software Components in System	Upgrade - General
CVERS1	Release Status of Software Components in System	Syntax, Compiler, Runtime
CVERS_ACT	Active Software Components in the System	Upgrade - General
CVERS_LAN	Component-Specific Language Status	Language Transport
CVERS_REF	Reference Table for CVERS Entries	Upgrade - General
CVERS_SUB	Relationship of Master Components to Subcomponents	Online Correction Support (Support Packages)
CVERS_TXT	Component Version System Information	Upgrade - General

[divyanshu_srivastava3 · Accepted solution]

and yes, PATPRDVRS and PATSWFEATR

[former_member182657]

Hi,

I will first upgrade ERP, then generate a new stack file for EHP7.

Yes it would be great to first upgrade from lower releases to EHP6 and than to EHP7 rather to search for any workarounds and any failure will cause you to achieve the upgrade schedule.

Regards,

Gaurav

[former_member1012268]

Hello World,

I managed to finish the ERP upgrade w/o problem.

I also think I found that the original stack file was based on a faulty SolMan configuration (stipulating the source system as EHP6, whilst it was EHP5).

But now I've got the unique problem of needing to setup the SolMan configuration for that system myself, from scratch, as I don't like to trust "those folks" to do it for me.

Its has been a while since I did this last time, but I'll open up a new thread for this.

[Former Member]

Hi Donaldo,

Wow! What a ride!

I've been upgrading from ERP6 EHP 6 on NW A.S 7.31 (aka NW A.S 7.0 EHP 3 just to confuse us!).  I'm using SUM 1.0 SP11, it has not been going that bad for me. Here are some general advices.

1. Make sure that SLD/LMDB contain the right info abour your systems before running MOPZ to create the stack.xml and downlowd the  EHP7 and related SPS archives. Even with all that MOPZ seems to omit some Add-Ons that SUM will complain about later! (The UVERS issues). I can see that from Source and Target System shown in you initial msg,  that there seem to be a problem with SLD/LMDB definition in Solman.

2. Update the current Kernel to the latest patch, tp, r3trans  and the latest SPAM/SAINT updates. SUM will ask you for that, so if you do it ahead of time you save time later during SUM run. And make sure you use the latest SUM SP.

3. Do not use SUM's "single " use the standard option even when upgrading a Single system like a Sanbox (SAP SUM developers sanitize the most widely used option the most!).

4. Delay whatever you can get away with during SUM run. Let SUM do the mandatory stuff and you will do the rest manually later. For example SUM proposes to integrate SPAU Transport Requests into the update process, but just a screen generation that may not work would complicate the whole upgrade! So unless you sure, defer SPAU until after SUM is done! If you allpied the latest SPAM/SAINT update before the SUM run, you can skip that when SUM asks, etc.

5. Read the SUM Guide it has some good info about how you reset SUM when it get's stuck, and other tips. Make sure you have the latest Active Version of the used SUM Central Note. They update very frequently!

6. You can actually delete from UVERS the entry that you don't care about and make SUM happy!

for example many of the components you see in System Status may not be used by your customer, e.g. the BP-CANW, BP*, EA-HR_for other countries , etc. SUM get's stuck when it sees in UVERS that a Component has same release in the curent system and in the current EHP and SPS that is being applied.  I run into the same problem , but in the EXtraction Phase, I reset SUM and it went through it fine the second time! I also tried to get the note you mentioned but SAP seems to haven't released it publicly!  Of course, you did the right thing by making a backup of the table before changing it!

Finally, If I had caught your problems earlier, I'd have said either:

A)you were done with the Update if you reached the PostProcessing Phase! You could have stopped SUM, applied all the stuff it complained about manually!  or,

B) In later messages, it sounds like things were corrupted?! Because the components of the NW A.S 7.4 : SAP_BASIS and SAP_ABA must show 7.4x and the Components of ERP 6.0 like SAP_APPL must show 6.17 if the update to EHP7 is correct! So at that point I'd say scrap it, reset SUM (as shown in the SUM Guide ) and start from scratch! If the Reset described in the Guide doesn't work (It didn't work for me!) try these steps!

1)Go to the directory SUM\abap\bin.

2)Enter the command "\SAPup reset prepare"

3)Delete the SUM directory.

4)End all SAPup processes on OS level before, if any exist.

5)Please try to run report RSUPGRES. This will solve UVERS inconsistency

6)Start everything again from beginning.

Finally be prepared, have fun and don't let SUM frustrate you!

Good luck!

Atman

[former_member182657]

Hi Donaldo,

Does this look right?
*********************************************************************************************************
Target System Version      
EHP5 FOR SAP ERP 6.0 SAP ERP 6.0 SAP EHP2 FOR SAP NETWEAVER 7.0 SAP PORTF AND PROJ MGMT 5.0 


Current System Version    
EHP5 FOR SAP ERP 6.0 SAP ECC 6.0 SAP ERP 6.0 SAP EHP2 FOR SAP NETWEAVER 7.0 SAP PORTF AND PROJ MGMT 5.0

If you're approaching for EHP7 than there is something wrong with the stack.xml file as target and current version still showing EHP5.You can verify the stack.txt file also.And any wrong modifications under stack.xml can push you back anytime in middle of Upgrade.

Also make sure your upgrade system should be fully sync under SM,so that correct stack.xml file generated.

Regards,

Gaurav

[former_member1012268]

I wrote that this time around I'll be upgrading ERP first (w/o EHP7).

Then set it up myself (correctly) in SM, and calculate a second stack to EHP7 from there.

Please don't tell me "you can go directly to EHP7", cause that was tried and failed miserably, and arguing about whose fault that was is of no use (to me) at this time.

I am trying to play it safe, to get the Sandbox up for functional testing of customer reports and DDIC objects ASAP.

*After* that has been accomplished, I'll try a second time with one single stack.

PS: For anybody else trying to do it this/my way, it is *essential* to be at least on SUM 1.0-SP10, as anything older will try to use the wrong kernel for the Shadow instance.

I had to replace mine with 7.20_EXT, because the 7.4x kernel will *not* take, and cause SUM to crash right in the middle of "Preprocessing"!

[former_member1012268]

Well, I pushed the button, SUM is churning away, its 2AM in the morning on my side of the globe and I (again) couldn't find any of that social life everyone else keeps talking about when giving their "guess what we did this weekend" speeches come Monday morning 😞

[Reagan]

Well it is 2:30 AM (almost) here now and I am still awake.

Get the stack file generated for EHP7 before you start SUM.

[former_member1012268]

I think I handled that topic already to exhaustion.

I will first upgrade ERP, then generate a new stack file for EHP7.

That might take me another 3 days, but that's better than waisting another 3 weeks - which I don't have.

BTW: I just found out that the beloved SUM is an absolute inferior piece of SW crap.

Any(!) partially downloaded SP file will screw it up so badly, that you can not recover - you must remove the whole SUM dir and start anew.

That even holds true when those partials don't have have *.sar as their extension (*.part in this case).

C'mon folks, that's just lousy programming!

[Reagan]

I will first upgrade ERP, then generate a new stack file for EHP7.

You already have an ERP system. I see you have an ERP 6.0 EHP5 system.

I am not sure what exactly you mean by upgrade it to ERP.

Check the SAP_APPL and EA_APPL components patch level on the system.

Regards

RB

[former_member1012268]

I did not wrote "upgrade to ERP", I wrote "upgrade ERP".

[former_member1012268]

Here is the link to the Stack Report File (it says its TXT, but its an HTML file you have to open in your browser):

http://pastebin.com/download.php?i=06mwSSbS

I am weary when I look at the "replaced" items, like

Replaced Products (4)

SAP NETWEAVER 04    SAP NETWEAVER    04    01200314690900000192

SAP EHP1 FOR SAP NETWEAVER 7.0    SAP NETWEAVER    SAP EHP1 FOR SAP NETWEAVER 7.0    01200314690900000866

SAP NETWEAVER 7.0    SAP NETWEAVER    7.0 (2004S)    01200615320900001250

SAP WEB AS 6.20    SAP WEB AS    6.20    01200615320900000563

that I might actually end up again with fewer Product Versions on the finished system then we had before - or am I just too tired to read this right?

[former_member1012268]

Does this look right?

*********************************************************************************************************

Target System Version     

EHP5 FOR SAP ERP 6.0 SAP ERP 6.0 SAP EHP2 FOR SAP NETWEAVER 7.0 SAP PORTF AND PROJ MGMT 5.0

Current System Version   

EHP5 FOR SAP ERP 6.0 SAP ECC 6.0 SAP ERP 6.0 SAP EHP2 FOR SAP NETWEAVER 7.0 SAP PORTF AND PROJ MGMT 5.0

*********************************************************************************************************

That is what SUM shows me now on its first screen.

When I had our old SolMan (also not my setup, but was used here for many years before I came) calculate the upgrade path for "ECC 6 EHP6", I went all the way, and he stuffed my Download Basket full with gigabytes of SAP Archives.

But all I see here is that the designated target will have one component less (SAP ECC 6.0), and nothing added(!)

That sounds rather like a downgrade to me - where the heck is the Upgrade info?

Truth be told, I normally trust MOPz enough that I don't try to interpret that first screen of SUM too much - but now I'm getting paranoid.

[Reagan]

Are you sure that you created the stack file for EHP7 ?

Based on the above information the current is EHP5 and the target is EHP5.

Regards

RB

[former_member1012268]

Its no use folks, I can not register a proper Product Instance for this system now in SolMan.

They *all* fail verification checks, and I am stuck with two messily product instances it will recognize.

"Portf & Proj Mgmt NW702" and "SEM".

I tried any and all incantations of ERP ECC 6.0 back & forth and none will take.

And since I can not be sure that it was (only)  a faulty definition on the original SolMan configuration that caused all this, I now have to choose a different approach - because I can *not* risk a repeat of this (I am already two weeks behind schedule by now).

1) Upgrade "SAP ECC 6.0" first

2) Calculate a new stack from there to "EHP7 for SAP ERP 6.0"

3) Live happily ever after or be screwed for life?

Anyone knows if such an approach is feasible?

[Reagan]

Is the production system maintained properly in the LMDB ?

If yes then create a stack file for that and copy that file for the QUA system EHP update.

I would refresh the QUA system with the production backup and bring it to the initial state and start the EHP7 update.

Doing first the EHP6 update and then doing an EHP7 update is a waste of time.

[former_member1012268]

I am already - almost - there.

Spend all night long rebuilding QUA from PRD, performed all the maintenance tasks for the SID change, applied kernel patch, corrected profiles.

Now I am ready to try again, BUT, I will not go straight to EHP7 again.

I *suspect* there was something wrong with the initial LMDB setup (because it wasn't me who set it up in the new SolMan system, I couldn't even verify the darn thing).

But I got no prove of that and there is the possibility that something is wrong with the system, or SUM or the entire process itself, preventing a clean upgrade straight to EHP7.

The way it looks now, if I spend the extra 2-3 days doing the ERP/EHP6 first, I can still get finished by Wednesday.

On the other hand, if I run into the same problem and burn another 1-2 weeks trying to resolve it (with next to no help from SAP), I am out of a job.

So I'd rather play it safe now, and then fix that new SolMan next time myself (I calculated this stack with our old SM system, were I have full access to).

My only worry is, is there is anything preventing me from going to EHP7, once I upgraded "ECC 6 EHP6" first?

[divyanshu_srivastava3]

If your source and target are correct in xml. If you usgae type is correctly defined. Then why would anything stop you from going to EHP7. Try with another sum version this time and remap components in source system with that in you xml generated.

[former_member1012268]

Are you trying to be dense on purpose?

I don't give a rat's rear about the supposed foolproofness of SAP tools.

I have been in this business for far too long to still entrust my livelihood to their promises.

What the heck good does "it should have worked" gonna do me with the boss if it screws up yet again?!

This time it would cost me my job to just trust that "SolMan will always get it right".

So I don't care if it was their fault that they set it up wrong in their SM, or if its something inherently problematic when going straight to EHP7 - I JUST WAISTED 3 WEEKS ON THIS !!

So I will not risk a repeat run, and that is why I asked the simple question:

Would there be anything preventing me from going to EHP7, once I upgraded "ECC 6 EHP6" first?

If you don't know the answer then no harm done, but please people stop trying to convince me to "do it again Sam"...

It failed the first time and unless you're ready to give me your job if it should fail again, I won't risk mine doing it over again on-a-hunch that it was just caused by a faulty SM configuration.

Because truth be told, MOPZ didn't complain either when it calculated that original Frankenstein Stack - so there don't seem to be many safeguards here.

And SAP's whole reply was "just restore and start from scratch" - their first level support didn't even attempt a root cause analysis.

I wish they would pay me for just keeping the tape drive busy all day long, I wish ....

[divyanshu_srivastava3]

Hey, my reply was in context to your last line - "My only worry is, is there is anything preventing me from going to EHP7, once I upgraded "ECC 6 EHP6" first?"

No one knows what went wrong with your upgrade. All I can think is a wrong component definition in solution manager, considering your ECC system was already in a good state, not a faulty system.

In fact, in one of my replies, I write you to choose X-Y and Y-Z path, which clearly means the same.

Since, you are convinced that you cannot make to EHP7 directly and safely, I asked you to read two verse. One was a note and other was a discussion.

Don't take my words otherwise, I still urge you to check the XMLs correctly for mapping source defined in xml and one that is in reality .

Good Luck..!!

[former_member1012268]

I read your note(s), it/they didn't mention anything related to a two step approach.

Hey, I myself was under the impression that "SUM + MOPz handle all".

But we are just fighting the IT folks from the corp that bought up our shop from taking over *everything*.

They sit a thousand miles away, but want to be in charge and in control - so if I tell them "you folks don't know what you are doing and you cost me three weeks of work because of that", then I'll be in hot water as it is.

Should I then fail again(!), because it wasn't (just) their Solution Manager configuration after all, then my goose would be cooked.

Then it would be me who is the idiot and them taking over our entire IT department.

Heck, I might even cause my fellow co-workers to loose their jobs, too.

Thanks but no thanks - I'll try the two step approach now.

If that fails, too, at least my OpenOffice still works - to update my resume 😉

There goes the weekend and the girl friend.

[former_member1012268]

Thanks for all the helpful replies (I mean it), but  now I've got a truly dumb question.

Just to be sure we did it the right way:

When going from "SAP ECC 6.0" to "EHP7 for SAP ERP 6.0", do you calculate one or two XML stack files for that?

In other words, does MOPZ recognize what upgrades/patches "SAP ECC 6.0" requires and automatically includes them in the stack for "EHP7 for SAP ERP 6.0", or do you have to do two SUM runs on this (one for "SAP ECC 6.0" first)?

[divyanshu_srivastava3]

If any upgrade is a direct one - for eg. from X to Z, then only one XML.

However, if you cannot reach Z directly from X, then you need to generate two XMLs.

One for X to Y. Upgrade system and update info in solman. Then generate XML from Y to Z.

In your case, you need to read 1064635 - SAP ERP Enhancement Packages: SP Stacks Release Info Note and

Divyanshu

[Reagan]

One is enough. too many will create a havoc

You just need to define the system properly in the LMDB and create a stack file.

MOPZ will define the queue based on the target version.

Also make sure the OS and DB are supported for the target EHP installation.

Regards

RB

[former_member1012268]

But shouldn't MOPZ tell me about that (as long as the system was properly entered in SolMan - something which I can not say for sure was done right)??

I mean, it gave no indication what-so-ever about any missing parts, and I read the few notes MOPZ mentioned while generating the stack file.

[divyanshu_srivastava3]

Mopz only know a technical system as defined in landscape database LMDB. So, a correct definition is all that is required for a correct XML. You can use verification check in LMDB for some misconfiguration.

[former_member1012268]

I did the DB & OpSys before starting SUM - and checked that the old SAP system was functioning w/o problems on the new DB+OpSys.

But Divyanshu's reply doesn't jive with this quote from the post he linked it to:

>In case of an "Enhancement package installation",

> you can include all the required support packages (source also) in one single step

> and the SUM will install these SP stacks as a part of Enhancement package installaiton.

That is *exactly* what I did, and as a result I got a messed up system, where I still need to apply dozens of SPs that were imported, but not applied by SUM.

There is something wrong here.

Would it be an issue if I first upgraded "ECC 6 EHP6" and then went to EHP7?

Maybe this way around I can avoid a repeat of this situation.

[former_member1012268]

When I finally got the authorizations to do that after the fact, I got all kinds of error messages thrown.

But the SolMan admin claims he only messed that up by making manual changes only later on, to help me maintain my partially patched system.

So I don't know any way to verify otherwise.

Now I think I got it almost set up right, the problem is I can not specify a major Product version w/o failing verification.

It won't take any major component for ""EHP7 for SAP ERP 6.0", or at least I don't know the right one to choose, and now I can't get the SM to calculate a correct stack for the missing Basis SPs.

I got the ""EHP7 for SAP ERP 6.0" directly from the system's "Status" dialog, and SolMan recognize things like Project Management.

But when I try to choose "SAP ERP 6.0" or "ECC Server" or the like, that entry always fails verification.

But w/o that component, I can't get MOPZ to calculate me a stack for the Basis parts of the system.

Anyone got any ideas on this one?

[Reagan]

What went wrong in the EHP update is not known unless the logs are thoroughly checked.

Whether there is a need to apply all the patches again in the system is something which should be clarified as I see the UVERS table in the target patch level but not the CVERS table.

There is a possibility that something went wrong in updating those tables.

Also I am aware there is a need to have ECC 6.0 SP stack 12 level for EHP7.

If you have the minimum requirements for the EHP7 then there is no need to do an EHP6 update and finally to EHP7.

[Reagan]

As you are in the post processing phase you should be done with the downtime phase.

I would first check the upgrade logs and see what went wrong.

Cross check the patch level of all the components in the system under SPAM - Package Level with the stack file.

Could you supply the UVERS table information please ?

It is possible that the PUT status in the table UVERS is causing the issue to continue with SUM.

Raise an OSS message.

RB

[former_member1012268]

Here is the content of UVERS:

Table:	UVERS
Displayed Fields:  13 of  13	Fixed Columns:	2	List Width 0250

---------------------------------------------------------------------------------------------------------------------------------------------------------

| |COMPONENT

|NEWRELEASE|STARTDATE |STARTTIME|ENDDATE   |ENDTIME |PUTSTATUS|PUTTYPE|PUTMASTER |OLDRELEASE|MODEA01|MODEB01|MODEA10   |

---------------------------------------------------------------------------------------------------------------------------------------------------------

| |CPRXRPM	|500_702   |16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|500_702   |	|	|	|
| |EA-APPL	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-DFPS	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |EA-FIN	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|	|	|	|	|
| |EA-FINSERV	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |EA-GLTRADE	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |EA-HR	|607	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCAR	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCAT	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCAU	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCBE	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCBR	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCCA	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCCH	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCCL	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCCN	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCDE	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCDK	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCES	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCFI	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCFR	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCGB	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCHK	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCID	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCIE	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCIN	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCIT	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCJP	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCKR	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCKW	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCKZ	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCMX	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCMY	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCNL	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCNO	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCNZ	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCPH	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCPT	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCQA	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCRU	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCSE	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCSG	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCTH	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCTW	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCUN	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCUS	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCVE	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRCZA	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRGXX	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-HRRXX	|605	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |EA-IPPE	|400	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|400	|	|	|	|
| |EA-PS	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |EA-RETAIL	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |ECC-DIMP	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |ERECRUIT	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |FI-CA	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |FI-CAX	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |FINBASIS	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |INSURANCE	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |IS-CWM	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |IS-H	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |IS-M	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |IS-OIL	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |IS-PS-CA	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |IS-UT	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |LSOFE	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |MDG_APPL	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|	|	|	|	|
| |MDG_FND	|747	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|	|	|	|	|
| |PI_BASIS	|740	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|702	|	|	|	|
| |SAP_ABA	|740	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|702	|	|	|	|
| |SAP_AP	|700	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|700	|	|	|	|
| |SAP_APPL	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|605	|	|	|	|
| |SAP_BASIS	|740	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|702	|	|	|	|
| |SAP_BS_FND	|747	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|702	|	|	|	|
| |SAP_BW	|740	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|702	|	|	|	|
| |SAP_FIN	|617	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|	|	|	|	|
| |SAP_GWFND	|740	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|	|	|	|	|
| |SAP_HR	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCAR	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCAT	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCAU	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCBE	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCBR	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCCA	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCCH	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCCL	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCCN	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCDE	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCDK	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCES	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCFI	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCFR	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCGB	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCHK	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCID	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCIE	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCIN	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCIT	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCJP	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCKR	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCKW	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCKZ	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCMX	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCMY	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCNL	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCNO	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCNZ	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCPH	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCPT	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCQA	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCRU	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCSE	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCSG	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCTH	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCTW	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCUN	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCUS	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCVE	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRCZA	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRGXX	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_HRRXX	|604	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|604	|	|	|	|
| |SAP_UI	|740	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|	|	|	|	|
| |SEM-BW	|600	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|600	|	|	|	|
| |ST-A/PI	|01Q_700   |16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|01Q_700   |	|	|	|
| |ST-PI	|2008_1_700|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|2008_1_700|	|	|	|
| |TFTO	|320	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|320	|	|	|	|
| |TOPFLOW	|700_60	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|700_60	|	|	|	|
| |WEBCUIF	|747	|16.07.2014|15:41:04 |26.07.2014|10:42:36|S	|A	|	|701	|	|	|	|

---------------------------------------------------------------------------------------------------------------------------------------------------------

[former_member1012268]

There is now a new problem.

When I try to restart SUM (./STARTUP) it throws me the following error message:

**********************************************************************

Jul 29, 2014 10:56:07 AM [Error]: com.sap.security.core.server.secstorefs.NotFoundException: Could not find a record with key "J2EE/StandardSystem/Instances/array1/InstanceSidAdminUser/Password" in the store.

Jul 29, 2014 10:56:07 AM [Error]: Class com.sap.security.core.server.secstorefs.SecStoreFS method getStringValue has thrown the exception com.sap.security.core.server.secstorefs.NotFoundException

Jul 29, 2014 10:56:07 AM [Error]: Property J2EE/StandardSystem/Instances/array1/InstanceSidAdminUser/Password does not exist.

Jul 29, 2014 10:56:07 AM [Error]: Cannot load encrypted property with name J2EE/StandardSystem/Instances/array1/InstanceSidAdminUser/Password. See previous messages.

Jul 29, 2014 10:56:07 AM [Error]: Error while loading data model from file /mnt/sapcd/RMF/SUM/SUM/sdt/data/variables/JUP.J2EE.DataModel.xml. See previous messages.

Jul 29, 2014 10:56:07 AM [Error]: Could not load data model com.sap.sdt.j2ee.model.J2EEDataModel. See previous messages.

Jul 29, 2014 10:56:07 AM [Error]: Error while initializing service context.

Jul 29, 2014 10:56:07 AM [Error]: Can't initilize sdt service provider

Jul 29, 2014 10:56:07 AM [Error]: Creation of use case executor failed.

Jul 29, 2014 10:56:07 AM [Fatal]: Error during controller startup.

Jul 29, 2014 10:56:07 AM [Fatal]: SL Controller exiting.

***************************************************************

I have no idea where this is coming from, as I didn't perform *any* manual manipulations in the directory.

This messed up!

[divyanshu_srivastava3]

Hi Donaldo,

Can you check:

"/mnt/sapcd/RMF/SUM/SUM/sdt/data/variables/JUP.J2EE.DataModel.xml."

Check for corruption and permission of this XML file.

Divyanshu

[former_member1012268]

How do I check that?

I ain't that good that I could read/interpret an XML file like that in "vi" w/o instructions.

[former_member1012268]

The file exists, has correct permissions and is over 1400 bytes large.

That's all I can say w/o knowing what I am supposed to be looking for.

[divyanshu_srivastava3]

There is one note, but link is not working

SAP Note 1816635 - Error: Cannot retrieve value from descendant with path /J2EE/StandardSystem/Instances[1]/InstanceSidAdminUser/Password

Divyanshu

[former_member1012268]

When trying to access that note, I get an error message stating "This Document has not been released".

if you happen to know the content of that note, could you please tell me the relevant steps to fix this?

Thanks in advance