on 04-28-2011 3:44 PM
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?
Also check if you have any lock file in /usr/sap/trans/tmp directroy. if any remove it.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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.
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
This is probably a longshot, but also make sure you have plenty of free background processes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
85 | |
10 | |
10 | |
9 | |
7 | |
6 | |
5 | |
5 | |
4 | |
3 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.