PDS delta transfer (RIMODAC2) switches to initial load for unknown reason

[Former Member]

We run daily CIF jobs (one for each APO plant) in R/3 to send the delta master/transactional data each day to the APO system. We are seeing an issue with the CIF of the PDS data, where occasionally it will switch to an initial transfer even though it should just do an delta transfer. We run RIMODGEN to generate a new model, and then RIMODAC2 to activate the new model (and deactivate the old one) so this should always result in a delta transfer. I've been unable to determine why this is happening, there seems to be no pattern to when this happens. For example, we have 5 jobs running twice a day (morning and afternoon). One morning all 5 will do the delta like they should, but in the afternoon 2 may switch to initial transfer and the other 3 will stay as a delta load. The next morning and afternoon could be totally different combinations again. We thought maybe it had something to do with if there were no changes to transfer that day, but haven't been able to prove that yet, it doesn't look like that is the reason. This is becoming an issue because our largest plant takes over 4 hours to resend all PDS's and is getting too long to fit the rest of the batch schedule in.

Has anyone else had this issue where the delta PDS transfer automatically switches to an initial transfer when running RIMODAC2 program? Any idea why this could be happening? Any ideas will be appreciated!

[former_member1065957]

MR. Vaibhav Birwadkar,

Have you get any solution on your question, did SAP provide you a note on this issue, are you deleting the change point

everyday (BD22) ? we have the same problem after the we clean up the change point.

your response will be appreciated.

thanks.

- Howard Qiu

[Former Member]

Hi Kaci,

Please check on the following.

1) Whether you have configured all settings correctly in CFC9 transaction. (For Change transfer of master data, the indicator is 2 ie BTE transfer).

2) Tick mark activating the ALE change pointers gernally in IMG settings under the menu path

spro > SAP guide > APO > Basic setting for data transfer > change transfer of master data > activate ALE change pointers generally

3) For PDS data trasnsfers, try using this t-code curto_create, (for change transfers, please check the tick against change transfer in this t-code). This can be executed in test mode also for verifying the data transfer.

Please let me know your comments.

Regards

R. Senthil Mareeswaran.

[Former Member]

Senthil,

I have double checked points 1 and 2 from your note and all set are correctly. For number 3, we are running program CUSLNTRTO_CIF_REPORT (transaction CURTO_CREATE) daily as well to transfer the change pointers, but then we also run a RIMODGEN and RIMODAC2 to pick up any newly created PDS's, and the RIMODAC2 is where we are seeing this issue.

It appears that this issue occurs if at least 2 RIMODAC2 for PDS's start within 1 minute of each other. I think now it has something to do with database contention, trying to get an exclusive lock on the CIF_IMAX or CIF_IMOD table. We are trying to stagger our start times by 5 minutes and see if that resolves the issue. We started this Friday with our afternoon jobs and so far none of them have thrown into an initial send, but we are giving it a few more days to prove this. However this isn't a permanent solution for the issue, just a work-around we are trying for now.

[Former Member]

Hi Kaci.

This seems to be a really critical issue.

Please let me know, whenever you have generated the PDS Delta, how do you go and start with the RIMODACT2 ???

I mean,

a) do you directly activate the newly genearted model (Integration Model)

or

b) first deactivate the old model and then start with the new one ?

The reason being, the RIMODINI generally start, when you Load the data for the first time (full update) or whenever you deactivate the model and then reactivate it. .

Please check, and let me know your inputs on the same.

Regards,

Prasad.

[Former Member]

First we run RIMODGEN in batch to generate a new model. Then we run RIMODAC2 as the next batch job step which will activate the newly generated model and in turn deactivate the previoiusly generated model at the same time. This should always result in a delta transfer, but we are seeing it occasionally result in an initial transfer (kind of like if we deactivated the previous model and activated the new model in separate steps...but we are not doing that).

[Former Member]

Hi Kaci,

This is something i have never heard of, but still you can try the following :

Try to deactivate the whole Model once, then Regenerate a new one and Activate the newly generated model. If at all there is some issue in the Model, it just might get cleared up. Hence, the model will work normally from the next delta updation.

This is just a trial method, but seems, it might work.

Please check and confirm.

Regards,

Prasad.

Edited by: Sanjay Shelke on Apr 18, 2009 11:41 AM

[Former Member]

Dear Kaci,

Let me clarify again your question. You mean to say if you start program RIMODAC2 then automatically it gets changed to RIMODINI? If yes, then you should raise the OSS.

If not, then how you are concluding that it has started initial transfer.

Best regards,

Vaibhav

[Former Member]

Thanks for your reply. To clarify, The program itself doesn't change from RIMODAC2 to RIMODINI, but RIMODAC2 will basically process like it is RIMODINI. Basically instead of just transfering the few PDS's that have changed since the last activation it resends every single one. I know it is doing this because if it's doing a delta it runs for a few minutes usually, but when it flips to a initial send it runs the same amount of time the RIMODINI would run (about 4 hours for our largest plant).

My college has raised an OSS message, but unless we can create a reproducable example SAP does not want to help us. If we could reproduce it, then we would know what was causing it...the issue is we don't know what is causing this.

Based on some additional searching I have done after opening this thread I'm starting to believe it has something to do with trying to get an exclusive lock on the CIF_IMOD table. It looks like if it can't get an exclusive lock it may try to kill the other process thinking it is a hanging session, and if two of our jobs happen to try to get an exclusive lock at the same time maybe something happens when it trys to kill the other session that throws it into an initial resend? The only part that doesn't make sense is that this only ever happens with the PDS, but we have steps for all Master data objects in the same job so I would think if this can happen for PDS's, it can happen for any of the other data objects, but never has occured for anything other than the PDS (at least that we've noticed). Maybe we need to single thread or PDS activations so they do not overlap? Has anyone ever encountered an issue with running multiple PDS delta activations at the same time?