Version copy: Can it fix COM errors

[Former Member]

Dear DP Experts,

I am struggling with COM routine errors on an unpredictable basis.. Error 40,020 pops up without any provocation of any kind.

Question: Can I use version copy (both master and transaction data) as a short cut to fix these errors that I have in source version. My fluke hope is system regenerates anchors and creates new time series in a new version but thats just an uneducated guess.

If this works I will derive a great pleasure in deleting the version that gave me pains.

Thanks

Guru.

[Former Member · Accepted solution]

Hi,

to my knowledge, version copy will not address your issues.

Did you already try reports /SAPAPO/TS_PSTRU_CONS_CHECK, /SAPAPO/TS_PSTRU_GEN and /SAPAPO/TS_PSTRU_TOOL?

thanks,

J.

[Former Member · Accepted solution]

Thanks Pablo,

Tried all of them a dozen times in countless instances in dialog and daily in background process chains. In fact some variants of this phenomenon are posted by me and others before. None of these programs apparently work even though all is green and pretends to repair in repair mode.

I am on a primitive version of APO. Sorry my back up job never backed up anything.. allegedly because my key figures are of "type apo". But thats no excuse to a unpredictable system with errors of this kind...viz. COM routine errors.

Any other tips ?.

The specific error is COM routine error 40020... No time series, No time buckets. All consistency and reorg reports are green still. The shuffler loads data but drill down pops this error.

Unfortunately no where in SAP ecosystem there exists a document that explains the root cause(s) of this issue. There could be several test scenarios that result in this error but SAP should have documented all that for their customers.. esp. when people like me have been reporting such issues on relevant forums like these.

COM Routine errors are VERY EXPENSIVE errors that should not happen in world class expensive softwares. No matter how old the release is, SAP should have given it a thought on how to keep the DB and Live Cache in sync in ALL WEATHER conditions..just like my good old Merc that never failed since 22 years from factory  and 3 change of owners and 11 accidents.

I have lots to complain on this live cache based architecture of APO but I am accumulating case histories for that now even though I am not a trained computing expert. Hopefully I publish it someday.

Any thoughts for now ?.

Thanks

Guru

[Former Member · Accepted solution]

Hi,

I completly see your point... I have to say I very rarely see these COM problems, and normally these routines solve them... let's see... If you have already tried these reports...

Have you activated again the MPOS? (no need to deactivate, just activate) Sometimes you change the BW structure of the MPOS (say you add a navigational attribute) and this is not handled well by the system until you activate MPOS again. Does your error appear for all characteristics, or just some of them?

sorry not being of great help here...

[Former Member · Accepted solution]

Thanks Pablo for your prompt response. Much appreciate.

I have scheduled a copy to a new version. Will publish my findings. The helicopter view is I have something corrupt in my source but my target should be pristine.

Btw I never knew you could activate an already activated MPOS. . This is another brilliant tip. Let me try that as well. Once again my world class trainer never told such a thing existed for some good.

What does RE-Activation of MPOS actutally do?. Fix Dim-ID-SID links ?. Mines just a wild guess. I just activated master data of infoobjects and thats all to it. and per sap.help, I should NEVER touch an MPOS or its generated infocube in a production system. Is this just to scare the clueless consultants ?

Many Thanks

Guru

[Former Member · Accepted solution]

The error appeared at drilling on all characteristics in MPOS (all in my sdp94 header)

Actually this was my intuitive guess that one char could have issues because of some valid historical reasons but that I was able to fix that part. In fact I dont think that had anything to with this error because this issue has something to do with data that is already in planning area..notwithstanding what I was able to copy to planning area because of 10's of other reasons like missing master data et al.

[Former Member · Accepted solution]

After 60000 seconds in bg I had to kill this job as it was slowing down every program. The data is available in the target though..not identical to the source version. My box is the perfect environment for performance troubleshoot.

[former_member215376 · Accepted solution]

Hi Borat Sagdiyev,

I would like to ask if we have the same issue. We just recently experienced this and experience COM routine 40,020 twice already. We always face whenever we used RTSCOPY but not still sure as to why this happened. Might be prior to RTSCOPY something went wrong in the system. But still no clue. Also, when we checked the Planning Area, the planning version that we were using was already removed or deleted for unknown reason.

For any feedback, let me know.

Thanks,

AA

[Former Member · Accepted solution]

Oh... if planning version is deleted, what else is left 😞

In my case I have rebuilt the planning area again from the backup cubes and files, reloaded the entire data from source again.. history etc. If COM error 40,020 does not go away and your consistency check programs all look green, you are probably in trouble. In such situations, you rely on your back up data. If you do not have upto date back up data (back up of planning area), you can ask your demand planners if they have some future data (e.g. forecast, adjustments, demand plan.. whatever they call it). If your demand planners are sincere girls, they may have stored some future data in excel files to show it to their managers who do not use SAP. If you still can't get it, then I do not know what to do. Perhaps blame SAP and claim for damages caused.

Alternatively you can ask your BASIS guys to do a system/DB restore to a time when your system was working fine. This way you will loose all changes done recently and will have a system wide impact.

Thanks

BS

[Former Member · Accepted solution]

We also received these errors during copying order series data and time series data and SAP suggested to run the aggregate consistency check for the source and target on regular basis. Post this check the frequency of these errors have reduced considerably but not eliminated completely though.

Regards

Amit Chug

[former_member215376 · Accepted solution]

Thanks BS,

SAP didn't provide a very clear reason as to why this happened. To be frank, it happened twice already and now we are so serious to see what triggered this scenario. We have time series and live cache consistency checks in the systems. And it's showing green prior to the said deletion of time series.

We really need to know the root cause! Currently, we are loading the lost key figures data from our backup cubes.

Regards,

AA

[former_member215376 · Accepted solution]

Thanks Amit Chug,

Will check into this aggregate consistency checks. However, can you provide me a good reading material about this? When this should run and for what purpose etc.

Regards,

AA

[Former Member · Accepted solution]

AA,

I think trying to find the root cause is a waste of time. SAP has this spread all over with their random notes business. By doing so you are probably doing a free consulting for SAP. Searching them all to know what really went wrong will take a month. It is possible that if you fly in some experts from SAP, they will come prepared with some secret programs to retrieve live cache data for you but that will cost you 350,000 USD at the least... if you are not big enough cash cow for them

In less than a month you can rebuild a complete whole new DP. I suggest, have another back up planning area too ready for use ay any moment. You can TSCOPY data from one planning area to another planning area every night. This is for emergency use so that planners can carry out their tasks. Though I am not sure how much time such a copy will take. SAP has 101 reasons (and 1001 notes) of pathetic performance when it comes to operations over large selections that systems from stone age dis in a few seconds.

I hope I was useful

Thanks and Good luck

BS

[former_member215376 · Accepted solution]

Thank you BS,

Will check and see your proposal re backup Planning Area.

By the way, not sure but do you think the error might triggered because of the following. This is what I've noticed while reloading the key figures data in our APO system.

- the timing of the backup of Planning Area to PSA coincides with the loading of data (1 key figure) from cube to Planning Area. Note that both jobs were finished without any issue.

Will this cause inconsistencies in the system? Especially on the time series?

Regards,

AA

[Former Member · Accepted solution]

Such a coincidence may create lock entries and might show job failures at worst but I do not think it should result in COM errors. This is just an educated guess. You never know what hidden notes SAP has on this one. I did come across a funny note long ago that when consistency check jobs are run, running DP program in parallel will be disastrous. That was like news to me as cons checks programs I was told were harmless programs that can be run anytime. As with everything else in SAP, you need to check a dozen things before concluding anything.

May be some other experts can comment on this.

Good luck

BS

[former_member215376 · Accepted solution]

Thank you BS,

Will take note on this. Another thing, before we knew that time series were deleted, we experienced the following:

(1) run RTSCOPY to copy key figure A to key figure B and to copy key figure A to key figure C; at the background, job log said COM routine 40,020 - no time series

(2) run RTSCOPY to copy key figure A to key figure B and to copy key figure A to key figure C; foreground, log said that job is being locked with another user (how this is happened? knowing that from the first background job, system said that there's no time series??)

(3) run RTSCOPY to copy key figure A to key figure B and to copy key figure A to key figure C; at the background, job log said COM routine 40,020 - no time series

Let me know your thoughts on the above. Thank you.

Dear Experts,

Any thoughts on my query? Appreciate your response and ideas.

Regards,AA

[Former Member · Accepted solution]

RTSINPUT is what you are probably referring to.. copying from cube to planning area. If the job says no time series then probably nothing is being copied because the planning area is being read as "deinitialized" even though on the screen it looks green. This is a possibly. What is on screen is not necessary what happens in the background.

Open the SM12 t-code to see the lock arguments. Lock arguments are created based on locking method used for planning area and selection criteria that is being processed and the overlap - synchronous, asynchronous. The more detailed the lock argument, lesser the lock conflicts... a general rule.

The best bet is to talk to the ABAP person. Give him/her this challenge. esp. those learning still as experts may pretend to be busy.

Thanks

BS

[former_member215376 · Accepted solution]

No RTSCOPY, copying data of key figure from certain source Planning Area to another target Planning Area. In our case, we use this RTSCOPY and our source and target Planning Area is actually the same.

But we'll check this. Thank you BS