2Advanced Transport Management Contents:Transport directory naming conventionsTransport tools and communication mechanismsImport process and troubleshootingObjectives:At the end of this unit you will be able to:Outline the files in the transport directoryExplain transport tools and their intercommunicationPerform imports and troubleshooting with tpClean-up the transport directory
3Transport Directory File Name Conventions DevelopmentSystem (DEV)Transport Directoryactlog DEVZ DEVZ900074sapnames SMITHdata R DEVcofiles K DEVbuffer QASlog ULOG 98_1 SLOG9803.DEV ALOG9803 DEVE DEV DEVP DEV DEVI QAS N QAS …..User SMITH creates change requestDEVK900073DEVK is released and exported to QASQuality 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.
4Introducing tp Export Import Quality Assurance Development R/3 Release andexport calls tptp ABAPcommunicationR/3Operating systemInsert table entriesinto control tablesInsert table entriesinto control tablesdatabaseDEVdatabaseQAStptpBuffer, logs, cofile,TPPARAMBuffer, logs, cofile,TPPARAMCallsCallsR3transR3transThe 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
5Helpful 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 functionalityDisplay help on specific tp-commandCheck the database destinationCheck the database connectionDisplay info on a transport requestDisplay number of registered requestsDisplay scheduling type of import dispatcherDisplay current setting of parametersDisplay status of serializationtp 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>.
6tp import all QAS client=200 tp Import CommandsDEVQASdatabasedatabaseRelease and ExportImportTransport Directorytp import all QAS client=200DEVK900004DEVK900008DEVK900016DEVK900013Imports 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
7tp 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 QASTASK UMODEDEVKDEVK900057DEVK900053STOPMARK Is a special entry (not a change request)DEVKThe 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.
8Introducing R3trans Export Import Quality Assurance Development R/3 Operating systemdatabaseQASdatabaseDEVtptpexit codeexit codewrite data files, logsread data files, write logsconnect, update, delete and insertconnect, readR3transR3transTransport DirectoryR3trans 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.
9ABAP Programs used in Performing Transports ExportImportRDDMASGLQuality AssuranceRDDGENBBRDDVERSL...RDD*-JobsRDDIMPDPDevelopmentstartsscheduleswrite logsRDDNEWPPR/3triggersOperating systemTRBATTRJOBtpTransport 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 DirectorydatabaseQAS
10tp 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.1st2nd3rd4th5th6th7th8th9thTASK DDIC | ACTIV | MAIN I | MC ACT | ADO I | LOG I | VERS F | XPRA | GENERA | UMODEDEVK | | | | | | | | |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 ImportABAP Dictionary importABAP Dictionary activationDistributionStructure conversion(*)Move nametabs(*)Main importActivation of the enqueue definitionsEnqueue conversion (*)Import of application defined objects (ADOs)Logical importVersioningExecution of user defined activities (XPRAs)Generation of ABAP programs and screensDDIC IACTIVImport processMAIN IMC ACTMC CONVADO ILOG IVERS FXPRAGENERAABAP 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
12Appendix: Log Files for Importing DEVK900021 DEVH QASDictionary importDictionary activationDistribution(*)Structure conversion(*)Move nametabs(*)Main importActivation of the enqueue definitionsEnqueue conversion(*)Import of application defined objects (ADOs)Logical importVersioningExecution of user defined activities (Xpra)Generation of ABAP programs and screensDDIC IDEVA QASDS QASACTIVN QASP QASMAIN IDEVI QASDEVMS QASMC ACTN QASMC CONVDEVD QASADO IDEVU QASLOG IDEVV QASVERS FDEVR QASXPRADEVG QASGENERA
13Import Process: tp and the Import Buffer dispatcherRDDIMPDPABAPDDICactivationConversionGeneration...DatabaseTRBATTRJOBdatabase../tmp - Log file(s)OS LeveltpR3transBufferThe 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)
14Import Process: R3trans dispatcherABAPRDDIMPDPDDICactivationConversionGeneration...TRBATTRJOBDatabasedatabaseDD importMain import../tmp - Log file(s)OS LeveltpR3transBufferDuring 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)
15Import Process: tp / ABAP Communication (1) dispatcherABAPRDDIMPDPDDICactivationConversionGeneration...DatabaseTRBATTRJOBdatabaseInsertsentriesTriggers../tmp - Log file(s)ReadsOS LeveltpR3transFor 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 BTo trigger the transport daemon RDDIMPDP in R/3, tp uses the operating system level tool sapevt.Buffer../log - Log file(s)
16Import Process: tp / ABAP Communication (2) dispatcherstarts RDD*-jobsABAPRDDIMPDPDDICactivationConversionGeneration...Checks and writes tableWrites statusInserts jobnumberDatabaseTRBATTRJOBdatabase../tmp - Log file(s)OS LeveltpR3transWhen 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 REach 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)
17Import Process: tp / ABAP Communication (3) dispatcherrestarts RDD*-jobsRDDIMPDPABAPDDICactivationConversionGeneration...Writes statusChecks tablesDeletesentriesDatabaseTRBATTRJOBWrites logsdatabaseDeletes entriesRestartsMonitors tables../tmp - Log file(s)OS LevelBuffertpThe 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 FAll 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
18Monitoring and Analysis: tp Log Files Transport subdirectorylogULOGSLOGALOGFor 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>.
19Monitoring and Analysis: Transport Tool Log Files DirectorytmpDirectory logR3transDEVI QASDEVI QAStpDEVV QASDEVI QASRDD*......Import processThe 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 codeAdditional error messagesEnd-user logsDetails for developers and hotlineWhether 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.
20Transport tool return codes tp Return Codestp return codes (rc)Transport tool return codes0 < rc < rc = max (tool-rc)16 < rc < 100 Combination of tool-rc andtp warning100 < rc < 200 tp warning200 > rc tp error0 Successful transport4 Warning8 Error12 Fatal errorFile systemDatabasetp 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>.
21Troubleshooting (1) Alert Monitor System Log (SLOG) Action Log (ALOG) View tp connection errorsLocate permission problemsSee RFC failuresView all tp return codesLocate what change request or generic phase produced a warning or errorReview 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.
22Transport Directory Troubleshooting (2) log actlog sapnames buffer SM37 check protocols of RDD* jobsSM31 - check tablesTRJOBJob overviewVV: Job started: Step 001 started: Fatal Error: Job abortedC11K NC11K NTRBATR/3Operating SystemTransport DirectorytpR3translogsapevtactlogsapnamesIn 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 systembuffer
23Appendix: tp Steps Mnemonic Step Program Environment E main export R3trans OSP test import R3trans OSH DD objects: import R3trans OSA DD objects: activation RDDMASGL R/3S DD objects: distribution RDDGENBB R/3N DD objects: conversion RDDGENBB R/36 DD objects: move nametabs pgmvntabs OSI main import R3trans OST import of table entries R3trans OSM enqueue activation RDDGENBB R/3G repository objects: generation RDDIC03L R/3V version update RDDIC R/3
25Appendix: TRBAT Function Codes Header JOBNAME Report Explanation=====================================================================X RDDDIC0L RDDDIC0L ADO exportJ RDDMASGL RDDMASGL Mass activator (new)B RDDTACOL RDDTACOL TACOB activatorS RDDDIS0L RDDGENBB DistributorN RDDGEN0L RDDGENBB Import converterM RDDMASGL RDDMASGL Mass activator (Enqueue)Y(n) RDDGEN0L RDDGENBB Matchcode converterO RDDGEN0L RDDGENBB Batch converter (not in Upgrade)D RDDDIC1L RDDDIC1L ADO importV RDDVERSL RDDVERSL Create versionR RDDEXECL RDDEXECL XPRA executionG RDDDIC3L RDDDIC3L GenerationFunction codesThe 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.
26tp & R3transQuestions & AnswersRoland HammSAP AG
27Copyright 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.