Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member226585
Participant
0 Kudos

And so. Here I will describe step by step, then, that you should pay attention to if there was a question of duty import of transport requests.

To determine the cause and solve it:

  • Run tx SE38 (SA38), execute the report RSRPTEST. This report tests tp status and configuration STMS
  • In tx STMS_IMPORT click on Goto -> tp system log, in this log, you can see the error of transfers, if any.
  • Check SM37 job mask RDD*, running or not. If not, plan the job and try to move the request again.
  • SM13 check for errors process UPDATE.
  • Check SM50 Are there free-BGD processes. If not, you must wait until the process is freed.
  • Check the file system level directories such as sapmnt, oraarch and so on. If they are overcrowded, it is necessary to extend them or clean, to release the space.

If, then, that the above does not help in resolving the issue, try the following things:

  • Move files from Katale /usr/sap/trans/tmp directory on another filesystem
  • Remove the requests with the status "in process" of import monitor in tx STMS
  • "Kill" All Processes at the OS level are running tp program. for Linux Execute the command ps -ef | grep tp and look PID processes and kill them with the command kill -9
  • Make sure that the job is active RDDIMPDP
  • Removing records from the tables and TRBAT TRJOB. As well as delete files * .LOC directory /usr/sap/trans/tmp
  • Reschedule the job RDDIMPDP c RDDNEWPP report in 000 and the other client as user DDIC and run the import request again
  • OS level can once tp kill the process and restart the import request.
1 Comment