Download SAP eBooks @ http://ebookssap.blogspot.com
TMS
1. The status in the TMS is "Import runs" although it is already finished or canceled.
In transaction STMS -> OVERVIEW -> IMPORTS you reach, by double-clicking, the import queue of the corresponding system. From there, via Goto -> Import Monitor, you reach the display of the status of both individual imports and Import all or Import subset. If the tp has already been started, you also see the tp process ID here and you can check at operating system level whether the process still exists (for example ps -ef | grep tp or via the Windows Task Manager). If the tp process still exists, execute the checks for hanging transports from note 556941. Additional notes are 486991 and 505771.
2. Why can I not see all requests in the import history?
See notes 316841 and 375230. In addition, requests whose name is longer than 10 characters can be viewed via transaction SPAM or SAINT.
3. The "large" truck is missing in the TMS symbols
The system is probably set to single import strategy. This can be set up from R/3 Release 4.6C via the transaction STMS -> TRANSPORT ROUTES -> Double-click on the corresponding system -> Tab title System Attributes, area 'Transport strategy' or according to note 194000 for smaller releases.
4. Both the truck and the menu option for the import are completely missing.
Here you must check whether in transaction STMS -> import overview -> double-click on the corresponding system there is an import client field with the requests or whether CTC=1 is set in the transport profile. If there is then also only one request in the import buffer, where there is explicitly no import client, the import does not work. Then add the corresponding import client in the TMS.
In transaction STMS -> OVERVIEW -> IMPORTS you reach, by double-clicking, the import queue of the corresponding system. From there, via Goto -> Import Monitor, you reach the display of the status of both individual imports and Import all or Import subset. If the tp has already been started, you also see the tp process ID here and you can check at operating system level whether the process still exists (for example ps -ef | grep tp or via the Windows Task Manager). If the tp process still exists, execute the checks for hanging transports from note 556941. Additional notes are 486991 and 505771.
2. Why can I not see all requests in the import history?
See notes 316841 and 375230. In addition, requests whose name is longer than 10 characters can be viewed via transaction SPAM or SAINT.
3. The "large" truck is missing in the TMS symbols
The system is probably set to single import strategy. This can be set up from R/3 Release 4.6C via the transaction STMS -> TRANSPORT ROUTES -> Double-click on the corresponding system -> Tab title System Attributes, area 'Transport strategy' or according to note 194000 for smaller releases.
4. Both the truck and the menu option for the import are completely missing.
Here you must check whether in transaction STMS -> import overview -> double-click on the corresponding system there is an import client field with the requests or whether CTC=1 is set in the transport profile. If there is then also only one request in the import buffer, where there is explicitly no import client, the import does not work. Then add the corresponding import client in the TMS.
Error Scenarios
1. I have error messages about logs not found during the transport.
This is usually caused by incorrect maintenance of the setting for the transport directory. Check in particular the parameters DIR_TRANS and TRANSDIR by referring to the advice given in note 556734, section "What do I need to consider when setting up the transport?".
2. The system reports a DB connect problem! What can I do?
For the test and as a basis for a further analysis, the command "R3trans -d " or "R3trans -x " can be used as useradm. A file trans.log is then also written in addition to the message via the return code of the attempt in the current directory. In the case of a connection problem, this contains details on the error message. R3trans mainly checks environment and database configuration files. If no error is found here, the parameters can also be checked from the transport profile with the call "tp connect pf=DIR_TRANS/bin/" (use backslashes with NT). The connection test can also be carried out from the TMS (OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> CONNECTION TEST or TRANSPORT TOOL). There are also additional notes on the respective database systems:
DB2: 152929, 83255, 136806
DB4: 515447, 67213, 69429
DB6: 80292, 53141, 167361
Informix: 85404, 112184
Microsoft SQL Server: 351586, 128126, 116735
Oracle: 193616, 400241, 403004, 134447, 443867, 445029, 437362, 505630
SAP DB: 39439
These notes do not apply to everything! They mostly only apply to certain R/3 or database releases. Only use the relevant notes that apply in each case!
3. When I create transport requests, they are always local!
Check in the TMS at the domain controller whether the transport routes are there. Usually the development system is the source system (the objects are created/changed there). From there, there are consolidation routes into one or several systems that can also be virtual. The consolidation route with transport layer SAP is intended for repairs to SAP objects. With customer transport layers for customer objects, the object must have a development class which is assigned to this transport layer. The corresponding development class can be displayed via transaction SE80.
4. The tp does not write requests to buffers of the subsequent system.
Check whether the transport routes are generally set up and fully activated and distributed. If it only concerns certain transports, check whether these are Workbench or Customizing requests or special transports (transport of copies/relocation). In particular with system copies and restores with incomplete recovery, you must be aware that afterwards the status of the buffer and the database may no longer agree. (For example, you import request C11K901234 into the consolidation system Q11 and then it is displayed in the Q11 buffer that the request is already imported in Q11. The request is not imported into the P11 system. Now you make a system copy from P11 to Q11. Now the request C11K901234 is not contained in Q11 (in SAP), however according to buffer Q11 it is imported).
5. An import seems to hang.
Check in the directory DIR_TRANS subdirectory tmp whether the import process regularly updates a log file for a certain import phase. The last entries in this log file provide information about what the import process is currently doing.
If the import hangs, you may find more error messages in the directory DIR_TRANS subdirectory log in the file SLOG. (YY are the last 2 numbers of the year and WW is the calendar week). The lines at the end of the file often even contain detailed messages on the error, such as RDDIMPDP is not scheduled. The following notes should also be checked: 12746, 71353, 26966, 449270.
If no helpful information has been found in the SLOG, you should check in DIR_TRANS subdirectory tmp whether there is a file there with extension .LO and this should be compared with note 12746. You can also check the tables TRBAT and TRJOB via SE16 or SM30 to see if there are old entries there.
For objects that enter the system via ADO or SDO import, you must check whether the corresponding jobs RDDIMPDP_CLIENTnnn were released here with the corresponding authorizations. With transports that are to be imported into several clients of a system, you must check whether you worked here with the correct unconditional modes in each case (the first import must be imported with U0 and the following one in each case with U1). Also, a further point which must be considered is the table delivery class belonging to the table. This controls which entries are imported with the various transports into which clients. You will find further information on this in note 2857.
7. An import supposedly has an error, but I cannot find an error in the log files.
This is usually due to the order-independent logs. In the order-independent steps, DDIC objects of other requests may also be edited. For example, the request to adjust a table remains for so long in the internal transport tables and is therefore also processed during a subsequent transport until the adjustment was successfully completed. An error can then be displayed for the subsequent request although its objects were all imported without any errors. Explanatory notes for this are 413993, 512493, 407116 and 330378. After every import, the order-independent logs should therefore also be checked.
If the system refers to canceled RDD* jobs, check the job log via SM37 and via ST22 the short dumps and via SM21 the syslog of the system.
8. A certain program has syntax errors after a transport into a non-development system.
Check whether the syntax errors also occur in the development system. If this is not the case, compare the versions of the program and of the function modules used by the program with the versions in the development system. Different versions can arise if corrections were not yet transported further in the development system or if the sequence of the import does not correspond to the sequence of the export. To solve the problem, import the last changes from the development system into the subsequent system as well.
This is usually caused by incorrect maintenance of the setting for the transport directory. Check in particular the parameters DIR_TRANS and TRANSDIR by referring to the advice given in note 556734, section "What do I need to consider when setting up the transport?".
2. The system reports a DB connect problem! What can I do?
For the test and as a basis for a further analysis, the command "R3trans -d " or "R3trans -x " can be used as user
DB2: 152929, 83255, 136806
DB4: 515447, 67213, 69429
DB6: 80292, 53141, 167361
Informix: 85404, 112184
Microsoft SQL Server: 351586, 128126, 116735
Oracle: 193616, 400241, 403004, 134447, 443867, 445029, 437362, 505630
SAP DB: 39439
These notes do not apply to everything! They mostly only apply to certain R/3 or database releases. Only use the relevant notes that apply in each case!
Check in the TMS at the domain controller whether the transport routes are there. Usually the development system is the source system (the objects are created/changed there). From there, there are consolidation routes into one or several systems that can also be virtual. The consolidation route with transport layer SAP is intended for repairs to SAP objects. With customer transport layers for customer objects, the object must have a development class which is assigned to this transport layer. The corresponding development class can be displayed via transaction SE80.
4. The tp does not write requests to buffers of the subsequent system.
Check whether the transport routes are generally set up and fully activated and distributed. If it only concerns certain transports, check whether these are Workbench or Customizing requests or special transports (transport of copies/relocation). In particular with system copies and restores with incomplete recovery, you must be aware that afterwards the status of the buffer and the database may no longer agree. (For example, you import request C11K901234 into the consolidation system Q11 and then it is displayed in the Q11 buffer that the request is already imported in Q11. The request is not imported into the P11 system. Now you make a system copy from P11 to Q11. Now the request C11K901234 is not contained in Q11 (in SAP), however according to buffer Q11 it is imported).
5. An import seems to hang.
Check in the directory DIR_TRANS subdirectory tmp whether the import process regularly updates a log file for a certain import phase. The last entries in this log file provide information about what the import process is currently doing.
If the import hangs, you may find more error messages in the directory DIR_TRANS subdirectory log in the file SLOG
If no helpful information has been found in the SLOG, you should check in DIR_TRANS subdirectory tmp whether there is a file there with extension .LO and this should be compared with note 12746. You can also check the tables TRBAT and TRJOB via SE16 or SM30 to see if there are old entries there.
For objects that enter the system via ADO or SDO import, you must check whether the corresponding jobs RDDIMPDP_CLIENTnnn were released here with the corresponding authorizations. With transports that are to be imported into several clients of a system, you must check whether you worked here with the correct unconditional modes in each case (the first import must be imported with U0 and the following one in each case with U1). Also, a further point which must be considered is the table delivery class belonging to the table. This controls which entries are imported with the various transports into which clients. You will find further information on this in note 2857.
7. An import supposedly has an error, but I cannot find an error in the log files.
This is usually due to the order-independent logs. In the order-independent steps, DDIC objects of other requests may also be edited. For example, the request to adjust a table remains for so long in the internal transport tables and is therefore also processed during a subsequent transport until the adjustment was successfully completed. An error can then be displayed for the subsequent request although its objects were all imported without any errors. Explanatory notes for this are 413993, 512493, 407116 and 330378. After every import, the order-independent logs should therefore also be checked.
If the system refers to canceled RDD* jobs, check the job log via SM37 and via ST22 the short dumps and via SM21 the syslog of the system.
8. A certain program has syntax errors after a transport into a non-development system.
Check whether the syntax errors also occur in the development system. If this is not the case, compare the versions of the program and of the function modules used by the program with the versions in the development system. Different versions can arise if corrections were not yet transported further in the development system or if the sequence of the import does not correspond to the sequence of the export. To solve the problem, import the last changes from the development system into the subsequent system as well.
Setup & Further Information
1. Are there general recommendations for importing transports?
If possible, the TMS should be used and not direct tp calls.If possible, you should import transports if nothing else is running in the system (online/Batch/Batch Input/Direct input/...)or at least nothing that affects the objects contained in these transport requests.There should be at least two free background work processes in the system (note 26966), that can also be scheduled with high priority as of Release 4.6. All application servers must access the same transport directory which is set via the profile parameter DIR_TRANS.This is possible by attempting the call by double-clicking via the AL11. There are also test options from the TMS via OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> TRANSPORT DIRECTORY.Furthermore the programs tp and R3trans should be current.The versions can be checked with tp -V and R3trans -V.A function test of the tools can be checked from the TMS (OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> CONNECTION TEST or TRANSPORT TOOL).
2. What do I need to consider when setting up the transport?
All systems that create the same transport group in the TMS must use the same transport directory while systems from different transport groups must use different transport directories.The following notes are helpful when you set up the required directory accesses via share or mount: 28781, 62739, 45516, 117395, 201199, 538268.
Up to R/3 Release 4.0, the file TPPARAM must be edited directly in the DIR_TRANS/bin directory.As of R/3 Release 4.5, the parameters can then be maintained from R/3 in the TMS under SYSTEM OVERVIEW after you double-click on the corresponding system.The parameter TRANSDIR is automatically global (checkmark in column global) in the TMS.This global TRANSDIR can be different than the transport directory used by the group (if there are different groups).With the TPPARAM, TRANSDIR must correspond with DIR_TRANS.Furthermore the batch jobs RDDIMDP (for client 000) or RDDIMPDP_CLIENTnnn (for the respective client nnn) must be scheduled for every client.These jobs must also be released event-dependently and with sufficient authorizations (for example as user DDIC).This can be checked using transaction SM37.
3. Can I use the transport directory between NT and UNIX?
When you refer to note 28781 it is also possible to use a common transport directory between NT and UNIX systems.
4. How can I tidy up my transport directory?
If necessary, before the clean-up the files should be saved first because the logs provide information about system changes and may be needed for the revision.After that the older log files can be deleted via the commands "tp check all" and "tp clearold".You will find more detailed descriptions in notes 41732, 168175, 312843, and in the online documentation.
5. Are transports possible between systems with different Support Package versions?
Such transports are technically possible, but inconsistencies can occur between the versions of the transported objects.For example if you first import the Support Packages in the development system and then change an object with a transport request, the version of the transport request is valid there.If you first import the transport request in the subsequent system and then the Support Packages, the version of the Support Packages is active there.
6. Are transports possible between different R/3 releases?
Technically, such transports are often possible.However, the inconsistencies described above can occur between the object versions.Further technical and logical problems for the various releases are outlined in notes 60928, 120151, 126776 and 330267.
7. Are there any general points to note on switching tp and R3trans?
The versions of the tp and R3trans must always match the respective kernel release of the system and should be in the directory /usr/sap//SYS/exe/run.You can check the version and patch level with the commands tp -V or R3trans -V.See note 19466 for the update of both the R/3 kernel and the tools tp and R3trans.For the release upgrade via an upgrade, additional updates of these tools may be required in other directories.You must then read the information in the corresponding upgrade note or guide.
8. Where can I find more information on the transport?
- Course BC 325
- SAP Online Library -> Basis -> Change and Transport System (BC-CTS)
- SAP Service Marketplace, Alias /SWCHANGEMANAGEMENT
If possible, the TMS should be used and not direct tp calls.If possible, you should import transports if nothing else is running in the system (online/Batch/Batch Input/Direct input/...)or at least nothing that affects the objects contained in these transport requests.There should be at least two free background work processes in the system (note 26966), that can also be scheduled with high priority as of Release 4.6. All application servers must access the same transport directory which is set via the profile parameter DIR_TRANS.This is possible by attempting the call by double-clicking via the AL11. There are also test options from the TMS via OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> TRANSPORT DIRECTORY.Furthermore the programs tp and R3trans should be current.The versions can be checked with tp -V and R3trans -V.A function test of the tools can be checked from the TMS (OVERVIEW -> SYSTEMS and there R/3SYSTEM -> CHECK -> CONNECTION TEST or TRANSPORT TOOL).
2. What do I need to consider when setting up the transport?
All systems that create the same transport group in the TMS must use the same transport directory while systems from different transport groups must use different transport directories.The following notes are helpful when you set up the required directory accesses via share or mount: 28781, 62739, 45516, 117395, 201199, 538268.
Up to R/3 Release 4.0, the file TPPARAM must be edited directly in the DIR_TRANS/bin directory.As of R/3 Release 4.5, the parameters can then be maintained from R/3 in the TMS under SYSTEM OVERVIEW after you double-click on the corresponding system.The parameter TRANSDIR is automatically global (checkmark in column global) in the TMS.This global TRANSDIR can be different than the transport directory used by the group (if there are different groups).With the TPPARAM, TRANSDIR must correspond with DIR_TRANS.Furthermore the batch jobs RDDIMDP (for client 000) or RDDIMPDP_CLIENTnnn (for the respective client nnn) must be scheduled for every client.These jobs must also be released event-dependently and with sufficient authorizations (for example as user DDIC).This can be checked using transaction SM37.
3. Can I use the transport directory between NT and UNIX?
When you refer to note 28781 it is also possible to use a common transport directory between NT and UNIX systems.
4. How can I tidy up my transport directory?
If necessary, before the clean-up the files should be saved first because the logs provide information about system changes and may be needed for the revision.After that the older log files can be deleted via the commands "tp check all" and "tp clearold".You will find more detailed descriptions in notes 41732, 168175, 312843, and in the online documentation.
5. Are transports possible between systems with different Support Package versions?
Such transports are technically possible, but inconsistencies can occur between the versions of the transported objects.For example if you first import the Support Packages in the development system and then change an object with a transport request, the version of the transport request is valid there.If you first import the transport request in the subsequent system and then the Support Packages, the version of the Support Packages is active there.
6. Are transports possible between different R/3 releases?
Technically, such transports are often possible.However, the inconsistencies described above can occur between the object versions.Further technical and logical problems for the various releases are outlined in notes 60928, 120151, 126776 and 330267.
7. Are there any general points to note on switching tp and R3trans?
The versions of the tp and R3trans must always match the respective kernel release of the system and should be in the directory /usr/sap/
- Course BC 325
- SAP Online Library -> Basis -> Change and Transport System (BC-CTS)
- SAP Service Marketplace, Alias /SWCHANGEMANAGEMENT
No comments:
Post a Comment