# Using tp, the Transport Control Program SAP BASIS

The transport control program tp is the SAP program that administrators use for performing and planning transports between systems and also in upgrades of the SAP systems. The tp program is used by the CTO and the TMS. The tp program uses other special programs and utilities to perform its functions. Mainly, it calls the R3trans utility program. However, tp offers a more extensive control of the transport process, ensuring the correct sequence of the exported/imported objects, because the wrong order can cause severe inconsistencies in the system.

Administrators normally use tp for performing imports; it can also be used for exports, although the normal export process is automatic when releasing change requests. The export phase extracts the objects from the database and places them on files at the operating system level, together with a control file and a transport log. The export phase is done in the source system. The import phase has to be performed in the target system. In this phase, the exported objects are inserted into the database following the instructions on the control file that came along with the data files of the export.

Importing data causes a refresh (a synchronization) of the SAP buffers, which can cause performance problems if this is done often. For that reason, it is a good practice to schedule imports at times of less interactive work, such as at night or on weekends. Before you can start using the tp program, you should ensure that the tp program is set up correctly and the requirements met. The next section explains how to set up the tp program.

Setting Up the tp Program

The tp program is located in the standard runtime directory of the SAP system. This directory is /usr/sap/SYS/<SID>/exe/run. It is automatically copied in the SAP installation process.

The requirements for using the tp program are as follows:

• The transport directory /usr/sap/trans must exist. This is a requirement for the SAP system installation, so it should be there. Watch out for the correct ownership, which you set to the SAP administrator user account, <sid>adm.
• The transport directory must be accessible by every R/3 system taking part in the transport process. This also includes all the application servers. If an application server cannot access the /usr/sap/trans directory, then you must make sure that the background process for imports doesn't run in this system; otherwise it will fail because it will not find the needed files in the directory.
• The Workbench Organizer and the transport system must be initialized as indicated in a previous section with transaction SE06, which initializes and updates the needed control tables for transports.
• Transports are only allowed between systems with different names (different SIDs).
• Both the source system and the target system must have at least two background processes each. This is because the transport process automatically schedules and releases the needed jobs.
• You must log on as user <sid>adm to perform transports. Imports with tp always have to be performed in the target system, whereas exports with tp must be done in the source systems.
• The tp global parameter file, TPPARAM, must be maintained, specifying at least the hostname of the systems taking part in the transport process. This file is explained in a later in this section of this chapter.
• The import dispatcher process RDDIMPDP and RDDIMPD_CLIENT_<nnn> should be scheduled as background jobs in every system where imports will be performed. These jobs are automatically scheduled by the system when performing a client copy. If for any reason they are deleted, you can schedule these jobs by running report RDDNEWPP. These jobs are defined as periodic event triggered, meaning that tp sends a signal (an event) to the R/3 system and the job starts. These events are SAP_TRIGGER_RDDIMPDP and SAP_TRIGGER_RDDIMPDP_CLIENT.

The Transport System at the Operating System Level: Users and Directories

In a group of related SAP systems that are going to perform transports among themselves, a correct configuration of users at operating system level and of the file directory structure is essential. In a standard R/3 installation, the system correctly sets both the users and the directories. There might be, however, some circumstances where the configuration might change unintentionally or from previous system settings. The standard transport directory is /usr/sap/trans and is shared by all the systems.

Normally, one of the systems holds it physically while others access it via NFS (network file system) or with file shares. This is done so all the systems have access to the exported files and transport logs. Otherwise, a manual copy of the needed files must be performed. It is equally important to give the right system authorization for accessing this directory. All the subdirectories should have <sid>adm as the owner. To avoid permissions problems, the normal setting is to give read, write, and execute access both to the owner and to the SAP administrator group number, sapsys. At the same time, this group should be defined the same in all SAP servers. If the group number has been manually created,modified, or previously used by other applications, problems might arise. Exports are always automatically performed by SAP systems using <sid>adm. Imports are performed at the operating system level in the target system and users must be logged on as user <sid>adm to guarantee correct file permissions.

The installation creates the subdirectory structure beneath /usr/sap/trans. The subdirectories are as follows:

• bin. Contains the TPPARAM file, which is the global transport parameter file. Normally, the <sid>adm user positions in this directory to perform imports so that the tp program locates the TPPARAM at the default directory. Otherwise, the call to tp must include the location of the parameter file. Optionally, this directory might contain other files such as T_OFF.ALL or T_OFF.<SID>. These files can be used to deactivate permission for all or a particular system to perform exports.
• data. This directory contains the transport data files.
• log. Under this directory, all the individual and general transport logs, statistics, and trace files are located. Administrators should refer to this directory for troubleshooting functions.
• buffer. Contains special buffer files with the SID of every system in the transport group. These files include control information on the transports that will be imported into other systems and the order of them. A good monitoring and display of the buffers improves the management of all the transport processes.
• cofiles. This is the control file directory containing information about the steps of the transportable change requests as well as the return codes.
• sapnames. Contains information on SAP users performing exports and keeps track of the status for each change request.
• tmp. This is the temporary directory containing some auxiliary temporary files with control flags, semaphores, and so forth.
• actlog. This directory includes action log files for all the tasks and change requests. These files are only accessed and modified by the R/3 system.
• olddata. Contains archived transport files from other transport directories that are generated when the administrators perform the tp clearold command.
Additionally, the system might have two more optional directories:
• backup. This directory is used if you are going to perform logical backups with the R3trans program.
• serial. This optional directory is needed in the case that the serialization option of tp is used.

TPPARAM: tp Global Parameter File

The tp program uses a parameter file, TPPARAM, located in the bin subdirectory under the transport main directory (/usr/sap/trans) that defines many important parameters that directly affect the way tp works for performing exports or imports. Every time tp is executed, it has to know the location of the TPPARAM file. For this reason, administrators call tp from the bin directory. Otherwise, the location must be specified with the option pf =. if this option is not specified, then tp must search for the TPPARAM in the current directory. This allows for the creation of different parameter files, when administrators wish to perform special functions or wish to call the tp program from a different location than /usr/sap/trans/bin.

The TPPARAM file can contain lots of parameters that can be either

• Global, which are then valid for all the SAP systems in a group.
• Local, which are only valid for each SAP system. These parameters are preceded by the system name. For example: DD1/impdp_by_event = yes.
• Operating system dependent, in which case these parameters are preceded by a keyword corresponding to the specific operating system.
• Database dependent, which means the parameters contain a prefixed keyword corresponding to the specific database system.

Because there are many allowed parameters in TPPARAM, as with instance profiles, the parameters that are not specified will take a default value. Local parameters have precedence over global parameters. This system of precedence allows for having at the same time local and global parameters, which can be used for specifying different parameter values for special systems. The syntax on the file is very simple: comments are preceded by a # sign whereas parameters have the form of <Parameter> = <Value> for global values. If the parameter is preceded by a SAP system name and a forward slash (/), then the value only applies for that system. For example: DD1/dbhost = copi01.

When the parameters are only valid for a particular operating system, then you enter the keyword or acronym for the operating system and the | sign, for example, as4 | transdir = ... Valid keywords for operating systems are aix, hp-ux, osf1, sinix, sunos, wnt (Windows), and as4 (AS/400). Finally, when the parameters are database system dependent, the parameters are preceded by a database system acronym and the : sign. For example: ora: <parameter> = <value>. Supported acronyms of databases are ora (Oracle), inf (Informix), ada (Adabas D), mss (Microsoft SQL Server), db4 (DB2/400), and db6 (DB2 for AIX). Additionally, TPPARAM provides predefined variables that can be used when specifying parameters and that are converted at runtime. These variables must be specified with the format $(var_name), for example,$(dbname). For a list of predefined variables, refer to the online help documentation. Because there are so many possible parameters in the tp configuration file, only the most important ones are described here:

• TRANSDIR. This parameter indicates the transport directory that should be accessible by all the systems in a SAP group and with the same name. All the transport data files and log files are stored in different subdirectories beneath TRANSDIR. In UNIX systems, this parameter is TRANSDIR = /usr/sap/trans/. In Windows NT systems, this parameter is TRANSDIR = \<transport host>\sapmnt\trans\.
• R3TRANSPATH. Sets the name and location of the R3trans program that is used by the tp control program. The system will find the correct program as long as the imports are performed by the <sid>adm user in the target system, because the SAP administrator user profile includes the right path accesses. In UNIX systems, this parameter is R3TRANSPATH = R3trans. In Windows NT systems, this parameter is R3TRANSPATH = R3trans.exe.

Following are database-dependent parameters that the tp program needs to establish communication with the SAP system database. Only relevant Oracle parameters are introduced here:

• DBHOST. The name of the host with the database server. Both in UNIX and Windows NT systems, this would be DBHOST = <hostname>. For example: DBHOST = copi02.
• DBNAME. This parameter sets the name of the database instance, which normally matches that of the SAP system.
Two other global parameters that are always present in TPPARAM are
• ALLLOG. This parameter is used to specify the name of the log file that keeps information of the steps for all transports in the system. This file is always located in the /usr/sap/trans/log directory. Default value is ALOG $(syear)$(yweek), which indicates that an ALOG file is generated for every calendar week. For example: ALOG9705.
• SYSLOG. This parameter specifies the name of the file in which the transport control program keeps information about the imports performed to a certain system. Default value is SLOG $(syear)$(yweek). $(system). This generates a SLOG file every calendar week and with the name of the import system as the file extension. These files are also located in the transport log directory. For example: SLOG9708.TT1. Two useful parameters in TPPARAM for common functions of tp when communicating with the background import job of R/3 are • IMPDP_BY_EVENT. This is a boolean parameter that is either true or false. The default value is true and it means that the tp program will trigger the import background job of the SAP system (RDDIMPDP) whenever an import takes place. If it's set to false, then the import background job must be scheduled to run periodically to check if there are pending imports. You leave it set to the default true value to avoid hundreds of background job logs. This requires that the additional parameter SAPEVTPATH be set. • SAPEVTPATH. Must contain the complete path to the sapevt program. This program is the SAP event trigger program, which can send signals to the R/3 system. This parameter is only used if IMPDB _BY _EVENT is set to true. For example: DD1/ sapevtpath = usr/ sap/$(system)/ SYS/ exe/ run/ sapevt.
When tp is called with special option put, there are some parameters in TPPARAM that control the command files for starting and stopping both the R/3 system and/or the R/3 database. These parameters are
• STARTSAP. This is the location for the program that starts the SAP system. The default value is " ", which will not start the system when tp is called with the put function, unless you are performing a SAP system upgrade, in which case, the upgrade program will modify it when needed. Similarly, the other three parameters, which also default to " ", are as follows:
• STOPSAP. This is the parameter for stopping the SAP system.
• STARTDB. This is the parameter for starting the SAP database.
• STOPDB. This is the parameter for stopping the SAP database.

To display the values of the TPPARAM parameters for a particular SAP system, issue this command: tp showparams <sid>. For example: tp showparams DD1 Additionally, with the use of the "-D = <value>" option when calling the tp program, you can temporarily change individual parameter values, only valid for the current tp call. For example: tp import DD1K900052 PP1 "-D stoponerror = 1." For other TPPARAM parameters, please refer to the SAP online documentation under the transport control section.

Overview of Options for the tp Program

The tp transport control program allows system or transport administrators to perform all the management functions for the transport system. These functions are specified by entering options when calling tp. The list of available options can be obtained by issuing a tp help command. To display help for a particular option of the tp program, call the tp <command> where <command> is a valid option. The program tp includes functions for exporting, importing, performing buffer actions, managing disk space of the transport system, organizing information, and performing special functions. Only those options that are more useful in normal daily operative tasks are included here. More information about all available options can be obtained from the SAP online documentation library.

Informative options are as follows:

• tp showbuffer <sid>. This displays the transportable change requests ready for import to the <SID> system. For example: tp showbuffer TT1.
• tp count <sid>. This command option displays the number of requests in the <SID> buffer waiting for import. For example: tp count TT1.
• tp go <sid>. This command is just informative, and it shows the environment variables needed for the connection to the database of the <SID> system. This command is executed automatically by tp before logging on to the database. Issuing this command, however, does not log on. For example: tp go TT1.
• tp connect <sid>. This is another informative option to check whether the connection to the <SID> database is successful. It logs on to the database and then logs off. It displays a message on the screen displaying the result of the connection.
• tp checkimpdp <sid>. The output of this command shows the type of background job that is scheduled in the <SID> system: whether it is event periodic, just periodic, or not scheduled at all. For example: tp checkimpdp TT1.
• tp showinfo <transport request>. This informative option shows the header information of the transport request. You don't need to specify a <SID> system.
For example: tp showinfo DD1K900052.
Main options for cleaning up the transport subdirectories data, log, and cofiles are as follows:
• tp check all. This checks the transport directories looking for files that are not needed (not waiting for imports) and have exceeded a minimum age specified by parameters in TPPARAM. These parameters are DATALIFETIME, OLDDATALIFETIME, COFILELIFE, TIME, and LOGFILELIFETIME. This parameter displays a list of files that can be deleted and generates a temporary file with the list.
• tp clearold. This uses the list file generated by the tp check all command and deletes the files included in the list.
Command options for handling the transport buffer are as follows:
• tp addtobuffer <transport request> <sid>. Adds the transport request to the buffer for the <SID> system and places it as the last request to be imported. If this request was already in the buffer, it modifies its order and places it as the last request. For example: tp addtobuffer DD1K900052 PP1.
Caution Changing the order of transport requests might have unpredictable results.
• tp delfrombuffer <transport request> <sid>. The transport request is deleted from the buffer queue of the specified <SID> system. It does not delete the transport files from the directory. For example: tp delfrombuffer DD1K900052 PP1. Caution This command can cause changes in the import sequence and therefore might produce unpredictable results.
• tp setstopmark <sid>. This command option sets a special mark in the import buffer for the specified <SID> system. This is useful when issuing the import commands tp import all or tp put, in which cases the importing only processes those requested before the mark. When the system processes the import of all objects before the mark, it slops itself and deletes the mark.
• tp delstopmark <sid>. Deletes a slop mark from the <SID> buffer if it exists.
• tp locksys <sid>. This command locks the <SID> system preventing users other than DDIC or SAP* from logging on. This command is normally issued by upgrade utilities. However, users already logged on will not be affected by the call.
• tp unlocksys <sid>. Removes the lock on the <SID> system set by a previous tp locksys command.
• tp lock_eu <sid>. Sets the system change option of the specified <SID> to cannot be changed.
• tp unlock_eu <sid>. Sets the system change option of the specified system to the value it had before a previous tp lock_eu command.

The main import tp command options are detailed in the following section.

Working with Imports Using tp

Although transport administration and performing imports has become much easier using the TMS import functions, it is still necessary to know how the tp control program can be used for performing imports. There are many available command options for performing imports in the R/3 system. Most of them are used for special purposes, such as importing only certain objects, performing activations, and so on.The main and most commonly used commands for the tp program when performing imports are as follows:

• tp import <transport request> | all <sid> [options...]. The tp import command has a more complex syntax than the other tp commands, because it allows many options to be specified. The command allows the import of a single transport request or the import of all requests waiting for import in the buffer of the <SID> system (up to a stop mark). Examples are import of a single transport request: tp import DD1K900052 PP1; and import of all pending transport requests for system PP1: tp import all PP1. Available options for the tp import command are as follows:
• U<n>[<m>..]. To specify one or more unconditional modes. The next section describes the unconditional modes available. For example: tp import all DD1 U1.
• client<n> or client = <n>. Imports to a specified client. For example: tp import all DD1 client007 or tp import all DD1 client = 007.
• pf = <TPPARAM>. Specifies the exact path of the tp parameter file if it does not use the default one located under /usr/sap/trans/bin.
• D "<parameter value." Changes a TPPARAM value for the current call.
• silent. Writes the output of the command to the dev_tp file located under the SAP instance work directory.
• tp put <sid>. Imports all the transport requests registered for import in the SID buffer up to a stop mark. This option will perform a start and stop of the SAP system as specified in the parameters for TPPARAM. If the default values of the STARTSAP and STOPSAP parameters are set to " ", the call to tp put won't stop the system.

This option is mainly used when upgrading SAP systems. When the default parameters are set, then tp put is the same as issuing a tp import all. In order to perform imports, the administrator in charge of importing the objects into the target systems has to log on at the operating system level as user <sid>adm. Normally, the administrator imports all objects that are in the buffer waiting for an import. Because importing objects might reset the buffers, it is not convenient to launch imports during normal working hours. An alternative is to include a tp import all <sid> call in a shell script that can be scheduled using system utilities or specialized software for scheduling the import at more appropriate times.

When performing imports, the tp program performs all the necessary steps depending on the nature of the objects or data being transferred. It will perform the following steps:

• ABAP dictionary import. The tp program calls the R3trans utility to import the dictionary objects into the target system. The data are imported inactively so as not to disrupt the normal work in the target SAP system.
• ABAP dictionary activation. During this phase, the nametabs (runtime dictionary objects) are written inactively, so that the system can keep running. Enqueue modules are not activated during this phase for consistency reasons.
• A distribution program checks whether there are any pending actions to move the new and inactive runtime objects into the active system.
• Next, the tp program performs any required structure conversion for the objects in the transport.
• At this moment, the system can move the new dictionary runtime objects to the active runtime environment. Some inconsistencies could occur if the objects are being accessed by active users.
• The next step is the main import phase where all the data are imported with the R3trans utility. If the data are successfully imported and consistent, an automatic transport to another subscribed recipient system can take place.
• Then the tp program takes care of activating any enqueue modules present in the transport which cannot be handled as other dictionary objects. These modules are directly passed onto the runtime environment.
• The final steps are to import any application-defined objects, set version flags for the imported objects, execute XPRA reports in case of puts, generate any report or screen, and remove the transport request number from the system buffer. If you get error messages during any phase of the import, tp will stop any further actions. After looking at the log files and finding the cause for the error and solving the problem, you normally can start the import again. The tp program records the point at which the processing should be restarted.

Unconditional Modes in the tp Program

Unconditional modes are options that can be specified for exports or imports with the tp program and are intended for performing special actions on transport requests. Caution Use only unconditional options when you are sure of what you are doing. Otherwise, this can cause severe inconsistencies in the systems. The unconditional modes tell the tp program to overwrite the rules imposed by the objects as defined in the Workbench Organizer. For example, they allow the import of original objects when that's not permitted by the package.

Unconditional modes are numbers from 0 to 9, and they can be used in the options part of the tp call. They are always preceded by the letter U. Several unconditional modes can be used in the same command. For example: tp import DD1K900052 PP1 U18. This tells the tp to activate unconditional modes 1 and 8.

When using unconditional modes, the transport log usually issues warning messages. These are functions for every unconditional mode:

• 0. Known as overtaker. It can be used for importing from the buffer without deleting it and then it uses unconditional mode 1 to allow another import in the correct location.
• 1. During an import, the system ignores that this request was already imported, and it can be imported again.
• 2. During an import, this permits the overwriting of original objects.
• 3. During import, this allows the transport program to overwrite system-specific objects.
• 6. This allows for overwriting objects that are unconfirmed repairs.
• 8. This mode ignores transport restrictions based on the table classes.
• 9. This mode ignores whether the system is locked for this type of transport.

Managing Special Transports

Usually administrators should perform imports for all the change requests that have been exported for a particular system. This is accomplished by a tp import all command. This is the only way that tp can guarantee the right order for importing objects, avoiding some newer versions being overwritten by older ones. There are occasions, however, when special and individual transports must be used, for example, when performing urgent imports or for transferring client-specific data from different clients. In these cases, you must be extremely careful not to change the order of the individual change requests. These types of transports require the import for individual transport requests. For example: tp import DD1K900054 PP1. When performing individual transports, have a look at the buffer (tp showbuffer <sid>) and ensure that no other older change requests contain the objects that you are going to import individually. This process can take some time and requires the use of the transport information system.

For performing individual imports, SAP recommends using the unconditional mode 0, which does not delete the change request from the buffer and will be imported again in a normal import, but ensures the correct release order for all change requests of a system. For example: tp import DD1K900078 PP1 U0. Normally, the data exported from a source client are imported into the client with the same number; however, the tp program permits specifying a different target client on the command line. For example: tp import DD1K900078 PP1 client = 007. This type of transport is valid for all the objects in the change requests that are client specific in the source client. You should be careful when issuing a tp import all command when trying to transport to more than one client. In those cases, the only way is to transport individually every change request to the required target clients.

The Interface between tp and ABAP

The actions that the tp control program performs are not performed alone. The tp program communicates with the ABAP runtime to execute the needed actions over the transported objects (for example, structure conversion, screen generation, and so forth). The interface between the tp program and ABAP is handled by the import dispatcher background jobs and the use of two system tables: TRBAT and TRJOB. By looking at the contents of these tables while an import is going on, administrators have another way of monitoring the transports online.

The dispatcher background jobs, as explained earlier, are RDDIMPD and RDDIMPDP _CLIENT _<nnn>, which schedule further jobs when needed. These jobs schedule themselves back to wait for further import steps or new imports. When a tp command is issued at the operating system level, it sends a signal to the background processing system for the RDDIMPDP to start, makes an entry in the TRBAT table for each transport request to import, and inserts the number of the background jobs in table TRJOB. At that moment, RDDIMPDP starts processing, first checking the TRBAT table to see if there are any pending imports. If it finds an entry, it launches additional ABAP programs as background jobs that will perform the necessary actions on the transport objects.

If any step is canceled, RDDIMPDP checks for entries still existing in table TRJOB and tries to restart the action. For this reason, the system needs to have at least two free background work processes. Table TRBAT contains several fields, including the change request number, function, return code, time stamp, client, special function, and log, which logs online the actions being performed during import. The unction and the return code indicate the step being performed and the status. Refer to the SAP online documentation in the transport control section for a description of the function keys and return codes of the TRBAT table.

0