1. tp & R3trans
Roland Hamm
SAP AG

2. Advanced Transport Management
Contents:
Transport directory naming conventions
Transport tools and communication mechanisms
Import process and troubleshooting
Objectives:
At the end of this unit you will be able to:
Outline the files in the transport directory
Explain transport tools and their intercommunication
Perform imports and troubleshooting with tp
Clean-up the transport directory

3. Transport Directory File Name Conventions
Development
System (DEV)
Transport Directory
actlog DEVZ DEVZ900074
sapnames SMITH
data R DEV
cofiles K DEV
buffer QAS
log ULOG 98_1 SLOG9803.DEV ALOG9803 DEVE DEV DEVP DEV DEVI QAS N QAS …..
User SMITH creates change request
DEVK900073
DEVK is released and exported to QAS
Quality Assurance System (QAS)
As the transport control program tp runs on many different operating systems, restrictive naming conventions are required. Change requests are named <source SID>K9<5 digits>, where K9 indicates a customer request. The six digits (including the 9) are a serial number.
The transport directory contains, for example, the following subdirectories:
actlog with files named <source SID>Z<6 digits> recording each action on a request or task (for example, creation, release, or change of ownership).
sapnames with files named after the user's logon name. A file is created for each R/3 user who performs transport actions, and updated when the user releases a request.
buffer with an import buffer for each R/3 System named after the SID. When a change request is released, the import buffer of target systems is updated.
data with files named R9<5 digits >.<source SID> containing the exported objects, and files beginning with D9 if application defined objects (ADOs) are transported.
cofiles with command files named K9<5 digits>.<source SID> (containing, for example, import steps to be performed)
log with all log files, such as ULOGs, ALOGs, SLOGs, log files named <source SID><action>9<5 digits>. <action SID> for each executed step, and log files named <action><date>. <action SID> for steps that are collectively executed, for example, step N (structure conversion) and step P (move nametabs). For a list of possible actions and related letters, see the Appendix.

4. Introducing tp Export Import Quality Assurance Development R/3
Release and
export calls tp
tp ABAP
communication
R/3
Operating system
Insert table entries
into control tables
Insert table entries
into control tables
database
DEV
database
QAS tp tp
Buffer, logs, cofile,
TPPARAM
Buffer, logs, cofile,
TPPARAM
Calls
Calls
R3trans
R3trans
The transport control program tp is a tool for controlling transports between R/3 Systems and for performing R/3 Release upgrades. tp tracks transports by controlling exports and imports of objects between R/3 Systems, ensures that the steps in exporting and importing objects are performed in the correct order, and ensures that imports into a target system are done in the same order as the exports from the source systems.
tp is an operating system level tool using special programs (such as C programs), operating system commands, and ABAP programs in R/3.
tp performs exports and imports separately. In the export phase, the objects to be transported are extracted from the database of the source system and stored in files in the transport directory. In the import phase, the objects are added to the database of the target system. An export should always take place immediately after the change request has been released, so that the objects can be freed for further modification.
There is no automatic mechanism that imports a request into a target system immediately after export. In R/3 Releases before 3.1H (without TMS functionality), imports are performed using tp commands at the operating system level. After 3.1H, using the TMS, imports are instead performed from within R/3.
Although most transport activities can be performed using TMS, you may find the need to use tp commands for exceptional cases. Because import buffers and import queues are identical, using tp and using TMS produces consistent results.
Transport Directory

5. Helpful tp Commands tp help Display help on tp functionality
tp go <SID>
tp connect <SID>
tp showinfo <request>
tp count <SID>
tp checkimpdp <SID>
tp showparams <SID>
tp status <SID>
Display help on tp functionality
Display help on specific tp-command
Check the database destination
Check the database connection
Display info on a transport request
Display number of registered requests
Display scheduling type of import dispatcher
Display current setting of parameters
Display status of serialization
tp commands are executed in the transport subdirectory bin by user <SID>adm, and are written tp <command> [argument(s)] [option(s)]
To display general information on the syntax of all tp calls, use tp help. To display a description of the syntax and function of a specific command, use tp <command> without any options.
To display a count of all requests registered for import into a specific system, use tp count <SID>.
To display the environmental variables required for logging on to the correct database of a specific system with the help of the values in the global parameter file, use tp go <SID>. Note that this command does not perform a connect; tp executes this command before a connect.
To test whether a connection to an R/3 System's database was successful, use tp connect <SID>.
To display how the import dispatcher RDDIMPDP is scheduled for a specific R/3 system, use tp checkimpdp <SID>.
To display all current settings of the parameter file, use tp showparams <SID>.
To display status information on the serialization of a specific system, use tp status <SID>.

6. tp import all QAS client=200
tp Import Commands
DEV
QAS
database
database
Release and Export
Import
Transport Directory
tp import all QAS client=200
DEVK900004
DEVK900008
DEVK900016
DEVK900013
Imports performed using tp at the operating system level should be restricted to exceptional cases, such as imports to multiple clients.
There are two commands for importing to a target system using tp at the operating system level:
tp import all <target SID> client=<client_number>. Analogous to the default import of TMS, this command imports all waiting change requests in the correct sequence (their export sequence).
tp import <change request> <target SID> client=<client_number> u0. Analogous to the TMS preliminary import, this command enables you to give individual change requests priority.
Importing individual requests is not recommended as the correct order of requests is not necessarily maintained, and thus newer versions of objects may be overwritten by older versions through the regular import of all waiting requests. To ensure that the objects imported through an individual transport are not overwritten by an older version, only use unconditional mode 0 (option u0) when starting individual imports. Using this mode is analogous to the TMS preliminary import and causes the change request to remain in the list of requests to be imported. When the regular transport takes place, the request will automatically be imported again in the export sequence. Individual imports only should be performed in exceptional cases.
Processing imports out of order can result in severe inconsistencies in the target system. These are hard to diagnose. If you wanted to import single requests not as preliminary import (NOT recommended), you would use tp import <change request> <target SID> client=<client_number> (without the option u0).
tp import DEVK QAS client=200 u0

7. tp Commands for Accessing Buffers
tp showbuffer <SID>
tp addtobuffer <request> <SID> [u<digit(s)>]
tp delfrombuffer <request> <SID>
tp cleanbuffer <SID>
tp setstopmark <SID>
tp delstopmark <SID>
Buffer for QAS
TASK UMODE
DEVK
DEVK900057
DEVK900053
STOPMARK Is a special entry (not a change request)
DEVK
The contents of import buffer files in the transport subdirectory BUFFER are organized as a table. Each line contains information on a specific transport request that is specified in column TASK. One column includes the unconditional mode that is linked to the transport request. Other columns specify import actions.
tp offers several commands for accessing buffers:
tp showbuffer <SID> displays buffer entries.
tp addtobuffer <change request> <target SID> registers the request as the last request to be imported. If the request has already been added for import, it is placed at the end of the queue.
tp delfrombuffer <change request> <target SID> deletes a single request from the buffer.
tp cleanbuffer <SID> removes successfully imported change requests from the buffer. This functionality is included in the command tp import all <target SID>.
tp setstopmark <SID> places a stopmark at the end of a buffer so that subsequent tp import commands only process the requests that are located before the stopmark.
tp delstopmark <SID> deletes the stopmark from a buffer.

8. Introducing R3trans Export Import Quality Assurance Development R/3
Operating system
database
QAS
database
DEV tp tp
exit code
exit code
write data files, logs
read data files, write logs
connect, update, delete and insert
connect, read
R3trans
R3trans
Transport Directory
R3trans is a transport tool at the operating system level used to transport data between R/3 Systems. R3trans is also used when installing new R/3 Systems, performing R/3 Release updates, and for logical backups. R3trans is usually called by other programs such as tp and the upgrade control program R3up.
For transports between R/3 Systems, to access the database, tp indirectly calls R3trans – by causing Unix to issue a forc(), Windows NT to issue a CreateProcess(), and AS/400 to issue a spawn(). During export, R3trans stores the object data extracted from the database in data files in the transport subdirectory data. The format of these data files, R3trans format, is independent of the platform. During import, R3trans reuses these data files.
Direct use of R3trans is not supported but may be required in exceptional cases. In case of transports, R3trans should always be used through tp. Import steps differ for the different object types. Further activities may be required in addition to R3trans activities. tp ensures that all export and import steps, including R3trans activities, are completed successfully.
Upward compatibility: R3trans writes data using a standard R/3 transport format. Thus you can export data with an old R3trans version and import data with a new version of R3trans. You can also transport between different databases or operating systems.
Note that although exports and imports are independent of the R3trans version, the database platform, or the operating system, SAP does not support using tp or R3rans for transports between different R/3 Releases.

9. ABAP Programs used in Performing Transports
Export
Import
RDDMASGL
Quality Assurance
RDDGENBB
RDDVERSL
...
RDD*-
Jobs
RDDIMPDP
Development
starts
schedules
write logs
RDDNEWPP
R/3
triggers
Operating system
TRBAT
TRJOB tp
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 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 RDDNEWPP.
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.
Transport Directory
database
QAS

10. tp Processing Sequence!
tp collectively processes each import step for all requests before proceeding with the next import step.
tp does NOT process all import steps for only a single request before proceeding to the the next request.
1st
2nd
3rd
4th
5th
6th
7th
8th
9th
TASK DDIC | ACTIV | MAIN I | MC ACT | ADO I | LOG I | VERS F | XPRA | GENERA | UMODE
DEVK | | | | | | | | |
DEVK | | | | | | | | |
DEVK | | | | | | | | |
DEVK | | | | | | | | |
DEVK | | | | | | | | |
DEVK | | | | | | | | |
DEVK | | | | | | | | |
DEVK | | | | | | | | |
tp processes each import step collectively for all requests in the import queue.
The required steps for each request are listed in the import buffer file. The contents of the buffer file is organized as a table. Each column represents an import step. The numbers in the columns indicate either if the import step is necessary, or the number of objects in the request that require the step.
In the example above, first the import step DDIC is processed for requests where it is required (DEVK and DEVK900092); then the ACTIV step (for DEVK and DEVK900092); then the MAIN I step (for all requests); and so on.
The 'tp import all' command does NOT process all steps for one request before moving on to the steps for the next request. For example, if you detect an error in an object that has already been released, you correct the object and release it again. 'Import all' then imports the whole buffer in the correct sequence and the faulty object is overwritten. Because the generation step is the last step and is performed only once for all objects in the requests, the faulty object does not affect your production system. Only the correct version of the report is activated and generated.

11. (*) = generic steps not dependent on requests
Steps during Import
ABAP Dictionary import
ABAP Dictionary activation
Distribution
Structure conversion(*)
Move nametabs(*)
Main import
Activation of the enqueue definitions
Enqueue conversion (*)
Import of application defined objects (ADOs)
Logical import
Versioning
Execution of user defined activities (XPRAs)
Generation of ABAP programs and screens
DDIC I
ACTIV
Import process
MAIN I
MC ACT
MC CONV
ADO I
LOG I
VERS F
XPRA
GENERA
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 state.
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 was exported. However, the import process does modify the object’s 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.
(*) = generic steps not dependent on requests

12. Appendix: Log Files for Importing DEVK900021
DEVH QAS
Dictionary import
Dictionary activation
Distribution(*)
Structure conversion(*)
Move nametabs(*)
Main import
Activation of the enqueue definitions
Enqueue conversion(*)
Import of application defined objects (ADOs)
Logical import
Versioning
Execution of user defined activities (Xpra)
Generation of ABAP programs and screens
DDIC I
DEVA QAS
DS QAS
ACTIV
N QAS
P QAS
MAIN I
DEVI QAS
DEVMS QAS
MC ACT
N QAS
MC CONV
DEVD QAS
ADO I
DEVU QAS
LOG I
DEVV QAS
VERS F
DEVR QAS
XPRA
DEVG QAS
GENERA

13. Import Process: tp and the Import Buffer
dispatcher
RDDIMPDP
ABAP
DDIC
activation
Conversion
Generation
...
Database
TRBAT
TRJOB
database
../tmp - Log file(s)
OS Level tp
R3trans
Buffer
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.
After the steps of the import process are completed, the command ‘tp delstopmark’ is performed automatically, and a ‘tp cleanbuffer’ deletes the transport requests from the import buffer.
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 abort.
../log - Log file(s)

14. Import Process: R3trans
dispatcher
ABAP
RDDIMPDP
DDIC
activation
Conversion
Generation
...
TRBAT
TRJOB
Database
database
DD import
Main import
../tmp - Log file(s)
OS Level tp
R3trans
Buffer
During the import process, tp reads the command file that includes all the necessary steps for the specific request and calls R3trans at the operating system level through a forc() for Unix systems, a CreateProcess() for Windows NT, or a spawn() for AS/400 environments.
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).
../log - Log file(s)

15. Import Process: tp / ABAP Communication (1)
dispatcher
ABAP
RDDIMPDP
DDIC
activation
Conversion
Generation
...
Database
TRBAT
TRJOB
database
Inserts
entries
Triggers
../tmp - Log file(s)
Reads
OS Level tp
R3trans
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. 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.
Request Function Return Code Timestamp T11K J T11K J T11K J HEADER J B
To trigger the transport daemon RDDIMPDP in R/3, tp uses the operating system level tool sapevt.
Buffer
../log - Log file(s)

16. Import Process: tp / ABAP Communication (2)
dispatcher
starts RDD*-jobs
ABAP
RDDIMPDP
DDIC
activation
Conversion
Generation
...
Checks and writes table
Writes status
Inserts job
number
Database
TRBAT
TRJOB
database
../tmp - Log file(s)
OS Level tp
R3trans
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): Request Function Return Code Timestamp T11K J T11K J T11K J HEADER J R
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.
Buffer
../log - Log file(s)

17. Import Process: tp / ABAP Communication (3)
dispatcher
restarts RDD*-jobs
RDDIMPDP
ABAP
DDIC
activation
Conversion
Generation
...
Writes status
Checks tables
Deletes
entries
Database
TRBAT
TRJOB
Writes logs
database
Deletes entries
Restarts
Monitors tables
../tmp - Log file(s)
OS Level
Buffer tp
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 Request Function Return Code Timestamp T11K J T11K J T11K J HEADER J F
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.
R3trans
../log - Log file(s)
Moves logs

18. Monitoring and Analysis: tp Log Files
Transport subdirectory
log
ULOG
SLOG
ALOG
For long-running imports, it may be helpful to monitor the log files written at the operating system level. All logs in the transport environment are stored in the transport subdirectory log. These logs include logs created by tp (ULOG, SLOG and ALOG), and logs created by the various transport tools.
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>. Each line in the ULOG file represents a tp command.
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 SLOG<YY><WW>.<SID>.
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 alllog. The default value is ALOG<YY><WW>.

19. Monitoring and Analysis: Transport Tool Log Files
Directory
tmp
Directory log
R3trans
DEVI QAS
DEVI QAS tp
DEVV QAS
DEVI QAS
RDD*
...
...
Import process
The various transport tools write a log for each transport action to the transport subdirectory tmp. After completion of the step, tp moves these logs from tmp to log. The log files are named <source SID><action><6 digits>.<target SID>, where the 6 digits are taken from the corresponding change request, and the performed action is represented by a single character (see also Appendix).
Each log file contains a table with seven columns showing:
The level for the transport protocol display in R/3. The possible levels are:
Performed actions and return code
Additional error messages
End-user logs
Details for developers and hotline
Whether the text is information, a warning, an error, or a program abort.
The language ID of the following text.
The message type, that is, the work area relating to the information.
The message ID in the related work area.
The message text. Up to 1000 message texts for each work area are defined in the R/3 repository.

20. Transport tool return codes
tp Return Codes
tp return codes (rc)
Transport tool return codes
0 < rc < rc = max (tool-rc)
16 < rc < 100 Combination of tool-rc and
tp warning
100 < rc < 200 tp warning
200 > rc tp error
0 Successful transport
4 Warning
8 Error
12 Fatal error
File system
Database
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.
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.
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 code>.

21. Troubleshooting (1) Alert Monitor System Log (SLOG) Action Log (ALOG)
View tp connection errors
Locate permission problems
See RFC failures
View all tp return codes
Locate what change request or generic phase produced a warning or error
Review individual log files at the operating system level.
The first step in troubleshooting transport errors is to eliminate the obvious setup issues using the alert monitor, which records all TMS transport actions. To use the alert monitor, use Transaction STMS and choose Monitor ® Alert monitor. The following information is displayed for each TMS function: the date and time, the user name, the TMS status message, and the target R/3 System. To display the full text of an error message, double-click on the error message.
R/3 logs are shown in a tree structure with three-levels:
The top level shows the SLOG file, used to monitor the transport activities of an R/3 System and determine the success of import requests.
If import failures are recorded in the SLOG file, drill down to the ALOG file and locate what particular import step produced the return code listed in SLOG.
From ALOG, to locate the log file for the specific request that produced the error and evaluate the cause of the problem, use either the import monitor or the relevant Change Organizer (the Workbench, Transport, or Customizing Organizer).
All log files that are not dependent on a specific requests (such as the log files for structure conversion and nametab moving) cannot be displayed in R/3. An import may abort and yet the log files displayed in TMS reveal no errors. This means the error was produced by one of the request-independent steps. To locate the step that recorded a failure, check the transport directory on the operating system level.

22. Transport Directory Troubleshooting (2) log actlog sapnames buffer
SM37 check protocols of RDD* jobs
SM31 - check tables
TRJOB
Job overview V V
: Job started
: Step 001 started
: Fatal Error
: Job aborted
C11K N
C11K N
TRBAT
R/3
Operating System
Transport Directory tp
R3trans
log
sapevt
actlog
sapnames
In R/3, check if the transport daemon RDDIMPDP is scheduled correctly and event-triggered. To check on the success of all related background processes (RDD*-jobs), go to the job overview (Transaction SM37). Monitor the job protocols.
The import buffer in subdirectory buffer provides information about the progress and success of imports.
Problems may result from wrong versions of tp or R3trans; tp not running (UNIX: ‘ps -ef | grep tp’); permission or share problems with the common transport directory; or not enough free disk space.
When analyzing a problem, compare the logs and buffer entries with the entries in tables TRBAT and TRJOB (Transaction SM31). If required, insert the transport request or header in TRBAT (use the codes in the Appendix) and restart RDDIMPDP.
If a communication problem between tp and R/3 is indicated, try calling sapevt on operation system level and see if it triggers RDDIMPDP.
File system
buffer

23. Appendix: tp Steps Mnemonic Step Program Environment
E main export R3trans OS
P test import R3trans OS
H DD objects: import R3trans OS
A DD objects: activation RDDMASGL R/3
S DD objects: distribution RDDGENBB R/3
N DD objects: conversion RDDGENBB R/3
6 DD objects: move nametabs pgmvntabs OS
I main import R3trans OS
T import of table entries R3trans OS
M enqueue activation RDDGENBB R/3
G repository objects: generation RDDIC03L R/3
V version update RDDIC R/3

24. Appendix: Complete List of tp Action Types

25. Appendix: TRBAT Function Codes
Header JOBNAME Report Explanation
=====================================================================
X RDDDIC0L RDDDIC0L ADO export
J RDDMASGL RDDMASGL Mass activator (new)
B RDDTACOL RDDTACOL TACOB activator
S RDDDIS0L RDDGENBB Distributor
N RDDGEN0L RDDGENBB Import converter
M RDDMASGL RDDMASGL Mass activator (Enqueue)
Y(n) RDDGEN0L RDDGENBB Matchcode converter
O RDDGEN0L RDDGENBB Batch converter (not in Upgrade)
D RDDDIC1L RDDDIC1L ADO import
V RDDVERSL RDDVERSL Create version
R RDDEXECL RDDEXECL XPRA execution
G RDDDIC3L RDDDIC3L Generation
Function codes
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 activation.
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 matchcode objects.
O: Converting all structure changes recorded in the table TBATG and generated by actions in the online system and not by the import.
R: Executing reports after put (XPRA).
S: Distributing actions – required to transfer the new dictionary structures into the runtime environment – to different steps.
X: Exporting application-defined objects.
Y: Converting structure changes to matchcode objects which were generated by the import and are recorded in table TBATG.
Note that actions B (TACOB activation), N, O, Y (structure conversion), and S (distribution program) only have header entries and no entries in field FUNCTION as they are change request independent.

26. tp & R3trans
Questions & Answers
Roland Hamm
SAP AG

27. Copyright 2000 SAP AG (All rights reserved)
Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.
Microsoft®, WINDOWS®, NT®, EXCEL®, Word® and SQL-Server® are registered trademarks of Microsoft Corporation.
IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation.
OSF/Motif® is a registered trademark of Open Software Foundation.
ORACLE® is a registered trademark of ORACLE Corporation, California, USA.
INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of The Open Group.
ADABAS® is a registered trademark of Software AG.
SAP, SAP-Logo, mySAP.com, R/2, R/3, RIVA, ABAP, SAP-EDI, SAP Business Workflow, SAP EarlyWatch, SAP ArchiveLink, ALE/WEB, BAPI, SAPPHIRE, Management Cockpit, SEM, are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other products mentioned are trademarks or registered trademarks of their respective companies.