Transport stall on EXECUTION OF REPORT AFTER PUT finished with returncode 0

[Former Member]

I am having an issue in my system where all transports stall on "EXECUTION OF REPORT AFTER PUT finished with returncode 0". I have noticed on the server when this point is reached, the tp.exe process hits 47% of cpu. It appears that its stuck here, possibly looping on something.

SLOG shows the following:

START imp single           X20        20110428152307              JKINARD      ip-0A7A557C 20110428151824767   
START DD IMPORT            X20 H      20110428152307              JKINARD      ip-0A7A557C 20110428151824767   
STOP  DD IMPORT            X20 H      20110428152312              JKINARD      ip-0A7A557C 20110428151824767   
START DD ACTIVATION        X20 A      20110428152312              JKINARD      ip-0A7A557C 20110428151824767   
START tp_getprots          X20 J      20110428152312              JKINARD      ip-0A7A557C 20110428151824767   
STOP  tp_getprots          X20 J      20110428152318              JKINARD      ip-0A7A557C 20110428151824767   
STOP  DD ACTIVATION        X20 A      20110428152318              JKINARD      ip-0A7A557C 20110428151824767   
INFO  TBATG CONVERSION OF  X20 N      not needed                  JKINARD      ip-0A7A557C 20110428151824767   
START MOVE NAMETABS        X20 6      20110428152318              JKINARD      ip-0A7A557C 20110428151824767   
START tp_getprots          X20 P      20110428152318              JKINARD      ip-0A7A557C 20110428151824767   
STOP  tp_getprots          X20 P      20110428152320              JKINARD      ip-0A7A557C 20110428151824767   
STOP  MOVE NAMETABS        X20 6      20110428152320              JKINARD      ip-0A7A557C 20110428151824767   
START MAIN IMPORT          X20 I      20110428152320              JKINARD      ip-0A7A557C 20110428151824767   
STOP  MAIN IMPORT          X20 I      20110428152321              JKINARD      ip-0A7A557C 20110428151824767   
INFO  TBATG CREATION OF EN X20 n      not needed                  JKINARD      ip-0A7A557C 20110428151824767   
START SET VERSION FLAGS    X20 V      20110428152321              JKINARD      ip-0A7A557C 20110428151824767   
START tp_getprots          X20 V      20110428152321              JKINARD      ip-0A7A557C 20110428151824767   
STOP  tp_getprots          X20 V      20110428152322              JKINARD      ip-0A7A557C 20110428151824767   
STOP  SET VERSION FLAGS    X20 V      20110428152322              JKINARD      ip-0A7A557C 20110428151824767   
START EXECUTION OF REPORTS X20 R      20110428152322              JKINARD      ip-0A7A557C 20110428151824767   
START tp_getprots          X20 R      20110428152322              JKINARD      ip-0A7A557C 20110428151824767   
STOP  tp_getprots          X20 R      20110428152428              JKINARD      ip-0A7A557C 20110428151824767   
STOP  EXECUTION OF REPORTS X20 R      20110428152428              JKINARD      ip-0A7A557C 20110428151824767   
START tp_getprots          X20 G      20110428152428              JKINARD      ip-0A7A557C 20110428151824767

"X20.LOB" is also stuck in the "tmp" directory. This keeps me from being able to import new transports without first deleting this item out of this directory. Are there any ideas on what might be going on here?

[former_member208104]

Also check if you have any lock file in /usr/sap/trans/tmp directroy. if any remove it.

[Former Member]

Thanks for the help! I ran Rafael's steps and that seems to do the trick. There is still an issue where the tp.exe program does not close itself down, and actually I find that there are multiple tp.exe processes. Why is this?

[former_member311580]

Hello Jeff,

TP process running "zombie" are habitually the consequence of some transport or import package failure. Also, can be due to a system crash or system shutdown while tp is running. This let the TMS system inconsistent and, after, we need to apply the above "recipe". The SAP system is not able to clean automatically the pending transports.

Remember that one of the steps in the recipe is to KILL all the tp.exe "zombie".

Some times we must apply the recipe several times until a consistent TMS. This is because the multiple steps of each transport "charged" and pending in the control tables. We must ensure a clean TMS environment before to restart our transport processes.

I recommend to you to ensure that TMS is already quiet and clean before to start again exporting/importing requests.

Regards,

Rafa

[Former Member]

Thanks again for the help. I ensured to do all the cleanups as listed before transporting, and the transport goes in fine, but still sometimes those zombie processes happen.

One thing about this server is that it is running on the Amazon EC2 Cloud, so its a virtual machine. I am wondering if something happens on the Amazon side where network or something drops causing tp.exe to fail every once in a while. Per a different thread I have open, I still receive the "RFC error text: timeout during allocate / CPIC-CALL: 'ThSAPCMRCV'" error sometimes, but I simply need to try again and eventually things work. Its very strange.

[former_member311580]

Hello Jeff,

I'm sorry to say that I do not know anything about "the cloud".

For the errror "RFC error text: timeout during allocate / CPIC-CALL: 'ThSAPCMRCV'", please try by setting profile parameter rfc/use_gwstart = 1 as explained in note 948636 and let me know if the connection still fails.

Also try to increase the parameter gw/cpic_timeout to at least a value of 120.

See notes:

581509 Reasons for "timeout during allocate"

516073 Timeout during connection setup

Of course, ensure to update your kernel patch to the last available, or at least to use the newest TP & R3trans tools.

Regards,

Rafa

[Former Member]

This is probably a longshot, but also make sure you have plenty of free background processes.

[former_member311580]

Dear Jeff,

These symptoms usually relates with a "dirty" TMS system.

It is usual after transport failures or system crashes.

I recommend to you to clean the TMS with the following recipe:

- Terminate all tp and/or R3trans process at OS level.

- Empty /usr/sap/trans/tmp directory -> This is important!: Move all contents or delete them.

- From STMS -> Goto -> Import monitor, delete all pending requests.

- Check and empty the tables TRBAT and TRJOB with SM30

- Re-schedule new RDDIMPDP job: log on with DDIC user in client 000 and run report RDDNEWPP.

After these steps your TMS will work correctly.

Of course, try always to use the most recent tools tp & R3trans along with the newest kernel as per note 19466.

Regards,

Rafa