Вы находитесь на странице: 1из 7



Transport not started:

1) Check in import monitor (gotoimport monitor) for start of import of particular request.
2) Check for any pop up error messages.
3) If transport is not started: Please check whether preexisting imports running in the
system for a long time(Ex: Auto imports scheduled is not completing for every hour, then
entries will be existing in the import monitor )
a. Then delete the entries of auto import in import monitor (which is running for
long days/time or no tp,R3trans running at OS level check all application
servers). Delete & add request again (why?), start the import of request.
4) Check the tp and R3trans versions and always it is recommended to have the latest
version of these files. For replacing these files there is no need of restart of SAP so you
can make a backup of the existing files and then put the new files in the exe directory.
R3trans and tp have dependencies to the shared database lib. New versions of tp and
R3trans are compatible in most cases but not in all cases!
5) Check whether the tp and R3trans are occupying some memory in the system at OS
level from task manager which indicates the transport is in process or hanged etc.
6) Check the <DIR_TRANS>/tmp-directory for semaphore-files
7) Check the STMS configuration is correct or not.
8) Check the Transport tool, Consistency check and the transport directory status from the
STMS. All these checks should be correct without any failure.
9) Check there are no errors in the STMS configuration and the system should be in the
Active status in the STMS.
10) Check SM21 and ST22 for any issues.
11) Check if the DIA and BGD work processes are free in SM50.

Transport Monitoring:
1) Check the tp system log and the import logs of the request in STMS or OS level for the
status of import.
2) Check the SLOG at the OS level or from SAP level AL11 for entries on which phase the
transport is going on. Got to the DIR_TRANS\log by mapping the network drive.
a. Map the network drive: Go to My computer: Tools Map the network drive In
the folder option give the trans directory path (for example:\\hs2032\trans.nt)
Its often better to use UNIX-tools because there are often too much files in the
transportdirectory and the explorer gets a timeout
3) Check for the updates in the tmp directory at OS of the particular transport when the
import is in process. This file shall be getting updated regularly.
4) Check for TRBAT entry. (GotoSE16enter table name TRBAT and click on
execute with F8 or click on


.check for any previous entry in the table.

TCS Internal

Page 1 of 7

5) Check for RDD* jobs. SM37RDDIMPDPcheck job running or not. These jobs should
be in released status in all the clients.
6) Check for import logs (select the requestgotoimport log). Expand the log, Note down
the PID and check in OS for tp in the particular PID.

The current ULOG file records all tp commands that are free of syntax errors, and
is named using the name convention ULOG<YY>_<one digit>. (the digit
indicates the quarter of the year) Each line in the ULOG file represents a tp
The SLOG file is used to monitor the transport activities of a specific R/3 System.
It contains a general overview of performed imports indicating the return code and
thus the success of each import. The name of the SLOG file can be set in the
parameter file TPPARAM using the global parameter syslog. The default setting is
The ALOG file records the return code for all transport steps handled in the
common transport directory. The name of the ALOG file can be set in the
parameter file TPPARAM using the global parameter all log. The default value is

Problem Solving:
1) Check the Import monitor of the queue once the import is started.
2) Check whether the phases in the import monitor are changing regularly.
3) If there are no updates are occurring check whether the tp is connecting to the database
or not and also verify the tp is working fine.
4) Check the connections of Transport Tool and the Consistency Check of the transport
program in the STMS.
5) Check whether the tp is able to read and write in the transport directory using the check
Transport Directory in STMS. You can do a sample test from the STMS tx.
6) Any problems in above 2 steps tests needs to be rectified other wise the import may not
proceed further.
7) Check the log file of the transport request by clicking on the view log option and check
that the phases are completing with RC 0 or 4.
8) Check the tp system log for the regular updates of the tp and for the phases in process.
9) Check the tp or R3trans executables at OS level for any uses are going in the system.
10) Check SM21 and ST22 for any DB related errors are occurring in the system while
transport import is in process.
11) Check for database locks (db01)
12) Check whether the RDD* jobs are in release status in all the clients.
13) Check whether the RDD* jobs are in Finished status once the import is in process so that
you can see that the import is running.
14) Check the tp system log for errors like RDDIMPDP job is not running.
15) If there is a message like RDD* jobs are not triggering then try to trigger them manually
either from SM64 or from SE38 using RDDNEWPP report with HIGH priority.
16) Check whether there are free at least 2 DIA and BGD work process are available in the

TCS Internal

Page 2 of 7

17) Check the TRBAT table for the entries related to your transport are present and also
check there are no prior entries existing, if entries are existing then you have to cross
verify whether the import for these requests are running or not.
18) Check also the TRJOB table for the related job of your transport.
19) Check in the directory DIR_TRANS subdirectory tmp (DIR_TRANS\tmp) whether the
import process regularly updates a file for a certain import phase. The last entries in this
file provide information about what the import process is currently doing.
20) You may get an error sapevtpath is not set in the tp system log, for this type of errors set
the sapevtpath transport parameter to the path of the sapevt executable.
21) If we receive an error <SID>.LOB is already in use (XXX) in the tp system log then follow
the below steps: Get the tp-process ID (PID) from content of the .LOB file.
Check if the PID exists on the host where tp runs .If it exists, the problem is not
the opportunistic locking but must be investigated by the support. Creates a new .LOB
file and will be blocked again with the message
"WARNING: \\ <hostname>\sapmnt\trans\tmp\ <SID>.LOB is already in use (XXX), I'm
waiting 5 sec
(20031209205043). My name: pid XXXX on YYYY. Perform the next step.
Login to the last tp-run host with a user that differs from the tp-user (why?) and
rename the .LOB file on the transport host.
Never never rename or remove a <SID>.LOB file while the corresponding tp is still alive.
If no other things helps, kill the tp (host/PID see the content of the file) before removing of
this file! This file is a semaphore file used by tp for the access to the import queue file and
is the most important semaphore. The tp uses also some other semaphore files for the
access to SLOG, ALOG, sapnames and cofile. These files are ending with .LOC or .LOS.
Of course, if the <SLOG>.LOC exists, no warnings is already in use can be written
into the SLOG. The <SLOG>.LOC is less important and I recomment to delete the file in
case of such problems. The R3trans controlfile is also used as semaphore to prevent for
parallel import of the same request.

TCS Internal

Page 3 of 7

Technical Information
ABAP Dictionary import with R3trans: All ABAP dictionary structural data is imported
inactively, thus enabling you to import into an active R/3 System.
Activation of ABAP dictionary and distribution: Runtime descriptions (nametabs) are
written inactively. After activation and running logical checks for the new dictionary
structures, the distribution program decides what actions are required to bring the new
objects into the running system.
Structure conversion: If necessary, changes are made to table structures.
Move nametabs: After the new ABAP runtime objects are put into the active runtime
environment, database structures are adjusted if necessary. From the beginning of this
step until the end of the main import, inconsistencies may occur in the R/3 System that
are removed at the end of the main import.
Main import with R3trans: All data is imported and the R/3 System returns to a consistent
Activation and conversion of enqueue objects: Objects that were not previously activated
are activated in this separate step after the main import. They are used immediately in
the running system.
Import of application defined objects (ADOs): These objects include forms, styles, and
printer definitions.
Logical imports: This phase is currently not active and is ignored during the import
process. The intentions of this phase will be to import data to a shadow client prior to
performing required Customizing transactions in the target client.
Versioning: Versions of Repository objects are only created on the R/3 System from
which the objects were exported. However, the import process does modify the objects
Version counter which is incremented for all Repository objects during import.
Execution of user-defined activities (XPRAs): XPRAs are objects that can be used to
start reports in the target system. The XPRA object has the same name as the report.
Generation of ABAP programs and screens: During this step, you can resume normal
business activities in the system.


For every transport request, tp writes an entry in table TRBAT. The import function
currently being performed for the request is represented by a character. For a list of
TRBAT function codes, see the Appendix.
In the example below, there are 3 change requests waiting for DDIC activation in the
table TRBAT. (the DDIC-activation has been finished in this example)
tp inserts a header entry to tell RDDIMPDP to start processing. Some activities that are
independent of transport requests, such as distribution and structure conversion, only
have a header entry in TRBAT. Return code 9999 indicates that the step is waiting to be
performed. For the header entry, tp inserts a B (for "begin") as return code.
To trigger the transport daemon RDDIMPDP in R/3, tp uses the operating system level
tool sapevt.

TCS Internal

Page 4 of 7

When RDDIMPDP is started, it checks the table TRBAT to find out if there is an action to
be performed such as mass activation, distribution, or table conversion. It sets the
header entry to R (for "run"), and starts the appropriate RDD* program as a background
task, reschedules itself, and exits. The activated program (in this example, the mass
activator) sets the status of the first entry in TRBAT to active (return code 8888):
Each of the required background tasks receives a job number generated by R/3
background processing. This job number and the step ID are inserted into table TRJOB
by the RDD* jobs. (the jobnumber will be written into TRJOB by RDDIMPDP)
The background tasks write their return codes in TRBAT and delete the corresponding
entry in TRJOB. Return codes of 12 or less indicate that the step is finished. In TRBAT,
the column TIMESTMP contains the finishing time. When all the necessary actions are
performed for all transport requests, the header entry is set to F (for "finished") by the
RDD* jobs.
Return Code Timestamp
All the background jobs log the steps they perform either in the database or in transport
subdirectory TMP.
tp monitors the entries in TRBAT and TRJOB. When the header entry in TRBAT is set to
F and TRJOB is empty, tp copies the logs of the completed steps from directory tmp to
log and deletes the corresponding TRBAT entries.
If problems are detected by tp when monitoring TRBAT and TRJOB, tp re-triggers
RDDIMPDP through sapevt. RDDIMPDP automatically recognizes if a previous step is
still active or was aborted by checking TRJOB and TRBAT. If a step was aborted,
RDDIMPDP restarts this step. Two background work processes must be available.
The function codes in TRBAT describe the actions being performed on a change request
during import:
B: Activating all dictionary objects in table TACOB with mass activation.
D: Importing application defined objects (ADO).
G: Generating reports and screens.
J: Activating all dictionary objects other than enqueue objects with mass
M: Activating enqueue objects in the change request with mass activation.
N: Converting all structure changes generated by the import and recorded in
table TBATG, other than the structure changes to match code objects
tp receives return codes from all the transport tools involved in an import process. tp's
own return code following exit is interpreted as follows:
0 to 16 indicates the maximum values of all return codes from transport tools.
0=OK, 4=warning, 8=error, 12=tool was aborted, 16=tool broke down
17 to 99 is a value that has been calculated from the return codes of the transport
tools and a tp warning, for example, that the buffer of the target system has no
write permission.

TCS Internal

Page 5 of 7

100 to 199 indicates warnings. Warnings mean that something went wrong and tp
could not perform all tasks. 100 to 149 are "normal" tp warnings, for example, that
RDDIMPDP cannot be triggered by sapevt. Return codes of 150 to 199 are rare
and indicate incorrect operation by a user. For example, a return code of 152 is
received if tp tries to import a request that is not included in the buffer.
200 or more indicates tp errors. For example, if a file could not be accessed as
required by the import process, the return code is 212.
More significant than the value of a return code is the accompanying text. To display the
text of a specific tp return code, use the tp command tp explainrc <value of return


The first step of an import process is the tp call, triggered by starting an import through
TMS or by a tp import command at operating system level.
To ensure that all transport requests stored in the buffer begin the import process
automatically, each time a tp import call is made, a tp setstopmark is executed.
This is true for an import of a queue, not for a single import
After the steps of the import process are completed, the command tp delstopmark is
performed automatically, and a tp clean buffer deletes the transport requests from the
import buffer. This is true for an import of a queue, not for a single import
After all involved tools have finished their work, tp exits to the operating system level and
writes a return code to the appropriate log file for the activity. For example, tp import and
tp setstopmark commands are recorded in the ULOG file.
Note: The command 'tp import' is reentrant. If an error occurs during import, after you
eliminate the error condition and restart tp, tp finds the correct point to restart.
By default, tp aborts if one import phase receives a return code larger than 8. The
TPPARAM parameter stoponerror defines what return code value should cause tp to
For each import step, tp passes a control file to the transport subdirectory tmp for use by
R3trans. R3trans reads the corresponding data files in the transport subdirectory data
and connects directly to the database to perform inserts or updates to the included
objects. After R3trans finishes performing inserts or updates, it passes an exit code to tp.
For each transport action, R3trans writes a log file in transport subdirectory tmp. After
R3trans completes its work, tp moves this log file to the transport subdirectory log.
During the import process, R3trans is called by the import steps ABAP dictionary import
(for the import of ABAP dictionary definitions), and main import (for the import of table
contents). And sometimes for the commandfile import to bring the objectlist not the
objects himself- into the system before the real import starts. The cmd-import will only be
performed as separate step when the versioning before import is activated or if its
explicitly requested (tp cmd ; used during supportpackage import). Another more
exotic importstep is the inactive import which is performed during the downtime
minimized import of supportpackages.
Transport steps implemented using ABAP programs include activating the ABAP
Dictionary, converting structures, and generating reports and screens. To execute these
steps, tp use the tables TRBAT and TRJOB to communicate with the various ABAP

TCS Internal

Page 6 of 7

programs. As these ABAP programs are run as background processes, there must be at
least two background work processes running in R/3.
When imports are performed, tp triggers the import dispatcher RDDIMPDP by sending
the event SAP_TRIGGER_RDDIMPDP with the help of the tool sapevt. In client 000 and
each client that is to receive imports, user DDIC must schedule the job RDDIMDP with
event-based scheduling. RDDIMPDP can be scheduled by running the ABAP program
Normally, RDDIMPDP is automatically scheduled after a client copy. To verify if the
required import dispatchers are scheduled, check the job overview using Transaction
SM37. The correct name of the import dispatcher for each client is
RDDIMPDP_CLIENT_<nnn> where nnn represents the client's name. The
corresponding event is SAP_TRIGGER_RDDIMPDP_CLIENT.
tp and the background jobs needed for transports communicate using table TRBAT,
which contains temporary data. tp inserts information into TRBAT specifying the steps to
be performed for a specific request. tp then triggers RDDIMPDP to read TRBAT and
execute the required programs as background jobs whose names start with RDD. For
example, RDDMASGL is for mass activation, RDDGENDB for conversion, and
RDDVERSL for versioning. Each RDD* job receives a job number that is recorded in
table TRJOB. The jobs report their current status back to TRJOB. The only thing what
the jobs are doing with the TRJOB is to delete the own entry at the end.

TCS Internal

Page 7 of 7